From sacadmin Sun Oct 18 19:10:59 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9J2Aw6a010901 for ; Sun, 18 Oct 2009 19:10:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9J2AuGY003965 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Mon, 19 Oct 2009 03:10:57 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRQ00D05OQ8WW00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 18 Oct 2009 20:10:56 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRQ005CZOQ8ZU90@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 18 Oct 2009 20:10:56 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9J2At0d006459 for ; Sun, 18 Oct 2009 19:10:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRQ00700OFW9F00@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 18 Oct 2009 19:10:55 -0700 (PDT) Received: from [129.150.220.13] ([unknown] [129.150.220.13]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRQ000H2OQ5VH20@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Sun, 18 Oct 2009 19:10:54 -0700 (PDT) Date: Sun, 18 Oct 2009 19:10:55 -0700 From: Hitendra Zhangada Subject: Fast-track : 2009/567 - Parallel Boot HV APIs Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Cc: Jim Quigley Message-id: <4ADBCAAF.8040301@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xgXSdU89jwI8fSpLKIL1JQ)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 12175 This is a multi-part message in MIME format. --Boundary_(ID_xgXSdU89jwI8fSpLKIL1JQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I am sponsoring this fast-track for Jim Quigley. This case defined few HV APIs needed to support Parallel Boot on RF based systems. See details in the attached document. This case is set t time-out on October 26, 2009. This case is seeking approval for, a minor/micro/patch OS binding and a minor/micro binding for the firmware. -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu --Boundary_(ID_xgXSdU89jwI8fSpLKIL1JQ) Content-type: text/plain; name=pboot-API.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=pboot-API.txt 1.0 Introduction ---------------- The following hypervisor APIs are required to support parallel boot. 2.0 PRI Delivery ---------------- For PRI delivery, a hcall API (see section 2.1) will be provided to retrieve the initial PRI data generated by host config. Future PRI Domain service should only push new PRI updates w.r.t the initial PRI generated by host config. Current existing PRI Domain service do not push initial PRI data. This API is implemented in the PBOOT group, 0x105. 2.1 HV API interface Definition ------------------------------- MACH_PRI Entry: trap# FAST_TRAP function# 0x170 arg0 buffer arg1 length Exit: ret0 status ret1 length This service copies the most current physical resource index (PRI) into the buffer indicated by the real address provided in arg0. If the argument *length* is non-zero, the argument *buf* is the real address of a data buffer, which must be aligned to the buffer size next highest power of two, (eg, if the buffer length is 500, the buffer address must be aligned on a 512-byte boundary). Upon success or EINVAL this service returns the actual size of the PRI in ret1. Programming note: a method for determining the appropriate buffer size for the PRI is to first call this service with a buffer length of 0 bytes.) Errors: EBADALIGN buffer is badly aligned ENORADDR buffer is an illegal real address EINVAL buffer length is too small ENOACCESS the calling guest is not the control domain ENOTSUPPORTED the PRI is not accessible using this API 3.0 OBP NVRAM Variables ------------------------ The Updates MD delivered to OBP is simply a data structure in the machine description format with a single root node containing string properties named after nvram variables and containing their non-default values. The Updates MD is also delivered to the LDom Manager on the mdstore domain service so that it can merge the updates into its own version of the control domain guest MD. When an LDoms configuration is subsequently saved to the SP, the variables in the SP variable store are flushed since they are now represented in the running control domain guest MD and in the stored LDoms configuration. If the SP is faulted when the host is powered on, when the control domain OBP boots it will fail to register the var-config-backup ds with vbsc. Any non-default nvram variables will be present in the guest MD on this first boot after poweron since hostconfig is able to include the latest non-default variables from the backing store in the guest MD it creates. Moreover, if OBP setenv command is used to update a variable, it will fail due to the missing variable ds, and so there will be no new non-default settings to persist after the SP is faulted. If any non-default variables are present in the variable backing store but not in the guest MD, they are only retrievable via the Updates MD. This happens if OBP setenv is used and then the control domain is soft reset with reset-all. This also happens if Solaris eeprom is used while the LDom Manager is not running and the control domain is rebooted. There are additional use-cases that can result in this condition. If the SP is faulted while in this condition, absent some recovery, the user will see the OBP variables revert to either a historical value still present in the guest MD or back to the default value. It is proposed that if the SP is faulted OBP will retrieve the Updates MD via a an HV API call. The Updates MD will be stored in the host flash and kept up-to-date by vbsc. Hypervisor will retrieve the Updates MD from the flash and make it available to the control domain OBP. The layout of the flash and the Updates MD in it is described in the host flash section. The control domain OBP will continue to use the variable ds when the SP is present. Non-control domain OBP will continue to only use the variable ds provided by the LDom Manager. The control domain OBP will only fallback to using the HV API when the var-config-backup ds fails to register. This might happen for three reasons: 1) the SP is faulted; 2) host is doing parallel boot and vbsc on the SP is not yet running; 3) a hw/fw bug causes the ldc/ds transport for the variable service to fail. While the HV API is necessary for the case where the SP is faulted, it also provides an ideal recovery when the SP is not faulted but still booting. This might happen during a cold poweron boot of host and SP (parallel boot), or it might happen if the host and control domain are rebooted in parallel (parallel reboot). 3.1 HV API ----------- This is analagous to the MACH_DESC and MACH_PRI APIs. It is implemented in the PBOOT group, 0x106. MACH_VARS Entry: trap# FAST_TRAP function# 0x176 arg0 buffer real address arg1 pointer to uint64_t for size of buffer Exit: ret0 status ret1 required size of buffer / returned data size This service copies the current Variable Updates Machine Description into the buffer indicated by the real address provided in arg0. If the argument *length* is non-zero, the argument *buf* is the real address of a data buffer, which must be aligned to the buffer size next highest power of two, (eg, if the buffer length is 500, the buffer address must be aligned on a 512-byte boundary). Upon success or EINVAL this service returns the actual size of the Variable Updates MD in the ret1. Programming note: a method for determining the appropriate buffer size for the Variable Updates MD is to first call this service with a buffer length \ of 0 bytes. A return value of EOK with a return length of 0 means that there is no OBP Variable Updates MD available. Errors: EBADALIGN buffer is badly aligned ENORADDR buffer is an illegal real address EINVAL buffer length is too small 4.0 Reboot Data ---------------- In SP degraded mode, if a domain is rebooted, Solaris would not be able to save the reboot parameters on the SP. Alternately, if SP goes down after reboot parameters are saved on the SP but before OBP is able to retrieve the parameters, OBP would not be able to boot Solaris using the specified parameters. In order to support a guest domain reboot in SP-degraded mode, a new HV API would be defined. Solaris would use this API to save the reboot parameters for the guest. The reboot parameters are saved with HV. When OBP is ready to boot Solaris, it would use the HV API to retrieve the reboot parameters and initiate the boot. Both Solaris and OBP need to negotiate the API version. If the API version supporting SP-degraded mode is detected, they should only use the HV API for reboot command parameters. If the API version supporting SP-degraded mode is not detected, the guest should continue to use the existing method of storing/retrieving the reboot parameters. 4.1 HV API interface Definition -------------------------------- The following APIs are available by negotiating version 1.0 of the REBOOT-DATA (0x110) API group. REBOOT_DATA_SET Entry: trap# FAST_TRAP function# 0x172 arg0 buf arg1 len Exit: ret0 status This service enables the guest to store data across a domain reset. The stored data will persist across a MACH_SIR. Initially the stored data will be cleared and the stored data length will be reset to the value zero. If the argument *len* is non-zero, the argument *buf* is the real address of a data buffer, which must be aligned to the buffer size next highest power of two, (eg, if the buffer length is 500, the buffer address must be aligned on a 512-byte boundary). The argument *len* is the size of the data in the date buffer to be saved. If *len* is zero, the argument *buf* is ignored, and any previously saved data is destroyed and the saved data length is set to zero. If this function returns successfully, the saved data and length have been updated. If the argument *len* is non-zero, *len* bytes of data from the data buffer defined by the argument *buf* have been saved. The saved data and data length may be retrieved via the REBOOT_DATA_GET API. If this function returns an error, the saved data and data length are unchanged. The minimum supported size of the internal data buffer shall be 512 bytes and the actual maximum may be higher. The maximum supported size is specified as 512 bytes. It is the guests responsibility to clear the reboot data after it has been retrieved. The data may be cleared by calling REBOOT_DATA_SET with a length of 0. Errors: EBADALIGN buffer is badly aligned ENORADDR buffer is an illegal real address EINVAL *len* larger than maximum size REBOOT_DATA_GET Entry: trap# FAST_TRAP function# 0x171 arg0 buf arg1 len Exit: ret0 status ret1 actual-len This service returns a copy of the currently saved reboot data. The saved reboot data may be set via the REBOOT_DATA_SET API. If the argument *len* is non-zero, the argument *buf* is the real address of a *len* sized data buffer, and must be aligned to the buffer size next highest power of two, (eg, if the buffer length is 500, the buffer address must be aligned on a 512-byte boundary). If the argument *len* is zero, the argument *buf* is ignored. Copies up to *len* bytes of stored data into the data buffer defined by the *buf* argument. In all cases, returns the actual length of the stored data in the return value *actual-len*. If *actual-len* is zero, no data is copied to the buffer defined by the *buf* argument, and there is no stored data. If the argument *len* is zero, return successfully with the return value *actual-len* set to the actual length of the stored data. If the argument *len* is non-zero, and less than the size of the stored data, returns the error code EINVAL. No data is copied. If the argument *len* is non-zero and greater than or equal to the size of the stored data, copies the stored data to the buffer defined by the *buf* argument. If the data buffer defined by the arguments *buf*, *len* is larger than the stored data, excess data bytes in the buffer defined by the arguments *buf*, *len* are undefined. Note: The client can easily determine the size of the stored data by calling this service with the *len* argument set to the value 0. Errors: EBADALIGN buffer is badly aligned ENORADDR buffer is an illegal real address EINVAL invalid buffer size --Boundary_(ID_xgXSdU89jwI8fSpLKIL1JQ)-- From sacadmin Mon Oct 19 14:31:15 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9JLVFAe013412 for ; Mon, 19 Oct 2009 14:31:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9JLUqoF022620; Mon, 19 Oct 2009 22:31:11 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRS00K176FZXP00@brm-avmta-1.central.sun.com>; Mon, 19 Oct 2009 15:31:11 -0600 (MDT) Received: from pkg.sfbay.sun.com ([129.146.90.56]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRS00A136FYT250@brm-avmta-1.central.sun.com>; Mon, 19 Oct 2009 15:31:10 -0600 (MDT) Received: from dropship.sfbay.sun.com (dropship.SFBay.Sun.COM [129.146.96.70]) by pkg.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9JLV9t8020159; Mon, 19 Oct 2009 14:31:09 -0700 (PDT) Date: Mon, 19 Oct 2009 14:31:09 -0700 From: Greg Onufer Subject: Re: Fast-track : 2009/567 - Parallel Boot HV APIs In-reply-to: <4ADBCAAF.8040301@sun.com> To: Hitendra Zhangada Cc: Firmware ARC , Jim Quigley , Tycho Nightingale Message-id: <1E9B9080-EA45-467B-ADC6-130D474709AF@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.1076) Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4ADBCAAF.8040301@sun.com> Status: RO Content-Length: 1555 On Oct 18, 2009, at 7:10 PM, Hitendra Zhangada wrote: > > MACH_PRI ... > If the argument *length* is non-zero, the argument *buf* is the > real address > of a data buffer, which must be aligned to the buffer size next > highest > power of two, (eg, if the buffer length is 500, the buffer > address must be > aligned on a 512-byte boundary). With hind-sight, the alignment should probably just match the mach- desc API with respect to buffer alignment constraints. I probably misled Jim when correcting his earlier draft. The mach-desc API states: The buffer provided must be 16-byte aligned. That text should be sufficient for all the hcalls in this case. > MACH_VARS > If the argument > *length* is non-zero, the argument *buf* is the real address > of a data buffer, which must be aligned to the buffer size next > highest > power of two, (eg, if the buffer length is 500, the buffer > address must be > aligned on a 512-byte boundary). And this as well. > of a data buffer, which must be aligned to the buffer size next > highest > power of two, (eg, if the buffer length is 500, the buffer > address must be > aligned on a 512-byte boundary). And this as well. > If the argument *len* is non-zero, the argument *buf* is the real > address of a *len* sized data buffer, and must be aligned to the > buffer > size next highest power of two, (eg, if the buffer length is 500, > the buffer > address must be aligned on a 512-byte boundary). And this as well. Cheers!greg From sacadmin Tue Oct 20 12:26:59 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9KJQxSr024904 for ; Tue, 20 Oct 2009 12:26:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9KJQr3n019964 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 20 Oct 2009 12:26:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRT00K1LVCYVX00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 20 Oct 2009 13:26:58 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRT00H4UVCXBG30@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 20 Oct 2009 13:26:57 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9KJQvNH025625 for ; Tue, 20 Oct 2009 12:26:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRT00H00VCQQ200@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 20 Oct 2009 12:26:56 -0700 (PDT) Received: from [129.153.85.16] ([unknown] [129.153.85.16]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRT00DAFVCVPU10@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 20 Oct 2009 12:26:56 -0700 (PDT) Date: Tue, 20 Oct 2009 12:26:55 -0700 From: Hitendra Zhangada Subject: Re: Fast-track : 2009/567 - Parallel Boot HV APIs In-reply-to: <1E9B9080-EA45-467B-ADC6-130D474709AF@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Cc: Jim Quigley , Tycho Nightingale Message-id: <4ADE0EFF.8060705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4ADBCAAF.8040301@sun.com> <1E9B9080-EA45-467B-ADC6-130D474709AF@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 2328 On 10/19/09 14:31, Greg Onufer wrote: > On Oct 18, 2009, at 7:10 PM, Hitendra Zhangada wrote: >> >> MACH_PRI > ... >> If the argument *length* is non-zero, the argument *buf* is the real >> address >> of a data buffer, which must be aligned to the buffer size next highest >> power of two, (eg, if the buffer length is 500, the buffer address >> must be >> aligned on a 512-byte boundary). > > With hind-sight, the alignment should probably just match the > mach-desc API with respect to buffer alignment constraints. I probably > misled Jim when correcting his earlier draft. The mach-desc API states: > > The buffer provided must be 16-byte aligned. > > That text should be sufficient for all the hcalls in this case. Sounds good. Jim has updated the specification. The alignment information is revised to say that it needs to be 16-byte aligned. I have copied updated specification to, http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2009/567/Materials/pboot-API.txt I have added version number (1.1) and today's date to this specification too. I consider this a minor change and so I am not changing the timer on this case. If any of you need more time then please let me know. Having at least one LGTM for this case would be nice. Thanks. > >> MACH_VARS >> If the argument >> *length* is non-zero, the argument *buf* is the real address >> of a data buffer, which must be aligned to the buffer size next highest >> power of two, (eg, if the buffer length is 500, the buffer address >> must be >> aligned on a 512-byte boundary). > > And this as well. > >> of a data buffer, which must be aligned to the buffer size next highest >> power of two, (eg, if the buffer length is 500, the buffer address >> must be >> aligned on a 512-byte boundary). > > And this as well. > >> If the argument *len* is non-zero, the argument *buf* is the real >> address of a *len* sized data buffer, and must be aligned to the buffer >> size next highest power of two, (eg, if the buffer length is 500, the >> buffer >> address must be aligned on a 512-byte boundary). > > And this as well. > > Cheers!greg > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Wed Oct 28 19:52:44 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9T2qhIo004587 for ; Wed, 28 Oct 2009 19:52:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9T2qhIo001256 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 28 Oct 2009 19:52:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS900H019BU7000@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Oct 2009 19:52:42 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS9006VJ9BUUU70@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Oct 2009 19:52:42 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9T2qgou009220 for ; Wed, 28 Oct 2009 19:52:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS900L00995ES00@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Oct 2009 19:52:42 -0700 (PDT) Received: from [129.150.33.38] ([unknown] [129.150.33.38]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS9004XO9BTWB60@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 28 Oct 2009 19:52:42 -0700 (PDT) Date: Wed, 28 Oct 2009 19:52:41 -0700 From: Hitendra Zhangada Subject: Re: Fast-track : 2009/567 - Parallel Boot HV APIs In-reply-to: <4ADE0EFF.8060705@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Cc: Jim Quigley , Tycho Nightingale Message-id: <4AE90379.5000702@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4ADBCAAF.8040301@sun.com> <1E9B9080-EA45-467B-ADC6-130D474709AF@sun.com> <4ADE0EFF.8060705@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 2988 Hitendra Zhangada wrote: > On 10/19/09 14:31, Greg Onufer wrote: >> On Oct 18, 2009, at 7:10 PM, Hitendra Zhangada wrote: >>> >>> MACH_PRI >> ... >>> If the argument *length* is non-zero, the argument *buf* is the real >>> address >>> of a data buffer, which must be aligned to the buffer size next highest >>> power of two, (eg, if the buffer length is 500, the buffer address >>> must be >>> aligned on a 512-byte boundary). >> >> With hind-sight, the alignment should probably just match the >> mach-desc API with respect to buffer alignment constraints. I >> probably misled Jim when correcting his earlier draft. The mach-desc >> API states: >> >> The buffer provided must be 16-byte aligned. >> >> That text should be sufficient for all the hcalls in this case. > > Sounds good. Jim has updated the specification. The alignment > information is revised to say that it needs to be 16-byte aligned. > I have copied updated specification to, > http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2009/567/Materials/pboot-API.txt > > > I have added version number (1.1) and today's date to this > specification too. > > > I consider this a minor change and so I am not changing the timer on > this case. If any of you need more time then please let me know. The timer for this case has expired BUT I am extending it till tomorrow, 10/29/09. There is a discrepancy with the group and function numbers. I would like Jim to address them before this case gets approved. The issues are as follows. For MACH_VARS API the group should be 0x105 and the function number is in conflict with TPM_GET API. ----- This is analogous to the MACH_DESC and MACH_PRI APIs. It is implemented in the PBOOT group, 0x106. MACH_VARS Entry: trap# FAST_TRAP function# 0x176 ----- > > Having at least one LGTM for this case would be nice. > > > Thanks. > >> >>> MACH_VARS >>> If the argument >>> *length* is non-zero, the argument *buf* is the real address >>> of a data buffer, which must be aligned to the buffer size next highest >>> power of two, (eg, if the buffer length is 500, the buffer address >>> must be >>> aligned on a 512-byte boundary). >> >> And this as well. >> >>> of a data buffer, which must be aligned to the buffer size next highest >>> power of two, (eg, if the buffer length is 500, the buffer address >>> must be >>> aligned on a 512-byte boundary). >> >> And this as well. >> >>> If the argument *len* is non-zero, the argument *buf* is the real >>> address of a *len* sized data buffer, and must be aligned to the buffer >>> size next highest power of two, (eg, if the buffer length is 500, >>> the buffer >>> address must be aligned on a 512-byte boundary). >> >> And this as well. >> >> Cheers!greg >> > > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Thu Oct 29 11:35:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9TIZBFs002887 for ; Thu, 29 Oct 2009 11:35:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9TIZBGI006116 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 29 Oct 2009 11:35:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSA00007GYMZH00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 11:35:10 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSA00HKPGYMSV60@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 11:35:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9TIZA4I029331 for ; Thu, 29 Oct 2009 11:35:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSA00J00GLE9Y00@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 11:35:10 -0700 (PDT) Received: from [129.153.85.32] ([unknown] [129.153.85.32]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSA00IBKGYHPU70@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 11:35:08 -0700 (PDT) Date: Thu, 29 Oct 2009 11:35:05 -0700 From: Hitendra Zhangada Subject: Re: Fast-track : 2009/567 - Parallel Boot HV APIs In-reply-to: <4AE90379.5000702@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Cc: Jim Quigley , Tycho Nightingale Message-id: <4AE9E059.1010305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4ADBCAAF.8040301@sun.com> <1E9B9080-EA45-467B-ADC6-130D474709AF@sun.com> <4ADE0EFF.8060705@Sun.COM> <4AE90379.5000702@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 3468 On 10/28/09 19:52, Hitendra Zhangada wrote: > Hitendra Zhangada wrote: >> On 10/19/09 14:31, Greg Onufer wrote: >>> On Oct 18, 2009, at 7:10 PM, Hitendra Zhangada wrote: >>>> >>>> MACH_PRI >>> ... >>>> If the argument *length* is non-zero, the argument *buf* is the >>>> real address >>>> of a data buffer, which must be aligned to the buffer size next >>>> highest >>>> power of two, (eg, if the buffer length is 500, the buffer address >>>> must be >>>> aligned on a 512-byte boundary). >>> >>> With hind-sight, the alignment should probably just match the >>> mach-desc API with respect to buffer alignment constraints. I >>> probably misled Jim when correcting his earlier draft. The mach-desc >>> API states: >>> >>> The buffer provided must be 16-byte aligned. >>> >>> That text should be sufficient for all the hcalls in this case. >> >> Sounds good. Jim has updated the specification. The alignment >> information is revised to say that it needs to be 16-byte aligned. >> I have copied updated specification to, >> http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2009/567/Materials/pboot-API.txt >> >> >> I have added version number (1.1) and today's date to this >> specification too. >> >> >> I consider this a minor change and so I am not changing the timer on >> this case. If any of you need more time then please let me know. > > The timer for this case has expired BUT I am extending it till tomorrow, > 10/29/09. There is a discrepancy with the group and function numbers. > I would like Jim to address them before this case gets approved. The > issues > are as follows. Jim has corrected the specification with the followings updates. I will copy the updated specification to the case directory and then send out mail to approve this case (in next hour or so). Group number for MACH_VARS = 0x105 (same as MACH_PRI). Function number for MACH_VARS = 0x178 (was 0x176). Thanks. > > For MACH_VARS API the group should be 0x105 and the function number is > in conflict with TPM_GET API. > > ----- > This is analogous to the MACH_DESC and MACH_PRI APIs. It is > implemented in the > PBOOT group, 0x106. > > MACH_VARS > > Entry: > > trap# FAST_TRAP > function# 0x176 > ----- >> >> Having at least one LGTM for this case would be nice. >> >> >> Thanks. >> >>> >>>> MACH_VARS >>>> If the argument >>>> *length* is non-zero, the argument *buf* is the real address >>>> of a data buffer, which must be aligned to the buffer size next >>>> highest >>>> power of two, (eg, if the buffer length is 500, the buffer address >>>> must be >>>> aligned on a 512-byte boundary). >>> >>> And this as well. >>> >>>> of a data buffer, which must be aligned to the buffer size next >>>> highest >>>> power of two, (eg, if the buffer length is 500, the buffer address >>>> must be >>>> aligned on a 512-byte boundary). >>> >>> And this as well. >>> >>>> If the argument *len* is non-zero, the argument *buf* is the real >>>> address of a *len* sized data buffer, and must be aligned to the >>>> buffer >>>> size next highest power of two, (eg, if the buffer length is 500, >>>> the buffer >>>> address must be aligned on a 512-byte boundary). >>> >>> And this as well. >>> >>> Cheers!greg >>> >> >> > > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Thu Oct 29 12:12:38 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9TJCbOq003968 for ; Thu, 29 Oct 2009 12:12:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9TJCXGc010038 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 30 Oct 2009 03:12:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSA00L01IOY1D00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 12:12:34 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSA00JU6IOY2120@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 12:12:34 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9TJCYkc026809 for ; Thu, 29 Oct 2009 12:12:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSA00A00IJ68H00@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 12:12:34 -0700 (PDT) Received: from [129.153.85.32] ([unknown] [129.153.85.32]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSA00KCZIOXIG70@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 29 Oct 2009 12:12:34 -0700 (PDT) Date: Thu, 29 Oct 2009 12:12:33 -0700 From: Hitendra Zhangada Subject: Re: Fast-track : 2009/567 - Parallel Boot HV APIs In-reply-to: <4AE9E059.1010305@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Cc: Jim Quigley , Tycho Nightingale Message-id: <4AE9E921.8000606@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4ADBCAAF.8040301@sun.com> <1E9B9080-EA45-467B-ADC6-130D474709AF@sun.com> <4ADE0EFF.8060705@Sun.COM> <4AE90379.5000702@sun.com> <4AE9E059.1010305@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 3911 On 10/29/09 11:35, Hitendra Zhangada wrote: > On 10/28/09 19:52, Hitendra Zhangada wrote: >> Hitendra Zhangada wrote: >>> On 10/19/09 14:31, Greg Onufer wrote: >>>> On Oct 18, 2009, at 7:10 PM, Hitendra Zhangada wrote: >>>>> >>>>> MACH_PRI >>>> ... >>>>> If the argument *length* is non-zero, the argument *buf* is the >>>>> real address >>>>> of a data buffer, which must be aligned to the buffer size next >>>>> highest >>>>> power of two, (eg, if the buffer length is 500, the buffer address >>>>> must be >>>>> aligned on a 512-byte boundary). >>>> >>>> With hind-sight, the alignment should probably just match the >>>> mach-desc API with respect to buffer alignment constraints. I >>>> probably misled Jim when correcting his earlier draft. The >>>> mach-desc API states: >>>> >>>> The buffer provided must be 16-byte aligned. >>>> >>>> That text should be sufficient for all the hcalls in this case. >>> >>> Sounds good. Jim has updated the specification. The alignment >>> information is revised to say that it needs to be 16-byte aligned. >>> I have copied updated specification to, >>> http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2009/567/Materials/pboot-API.txt >>> >>> >>> I have added version number (1.1) and today's date to this >>> specification too. >>> >>> >>> I consider this a minor change and so I am not changing the timer on >>> this case. If any of you need more time then please let me know. >> >> The timer for this case has expired BUT I am extending it till tomorrow, >> 10/29/09. There is a discrepancy with the group and function numbers. >> I would like Jim to address them before this case gets approved. The >> issues >> are as follows. > > Jim has corrected the specification with the followings updates. > I will copy the updated specification to the case directory and then > send out mail to approve this case (in next hour or so). > > Group number for MACH_VARS = 0x105 (same as MACH_PRI). > Function number for MACH_VARS = 0x178 (was 0x176). I have copied updated specification with the corrected group and function number at, http://sac.eng.sun.com/arc/FWARC/2009/567/Materials/pboot-API.txt HV API registry is also updated. This case is now approved for, a minor/micro/patch OS binding and a minor/micro binding for the firmware. > >> >> For MACH_VARS API the group should be 0x105 and the function number is >> in conflict with TPM_GET API. >> >> ----- >> This is analogous to the MACH_DESC and MACH_PRI APIs. It is >> implemented in the >> PBOOT group, 0x106. >> >> MACH_VARS >> >> Entry: >> >> trap# FAST_TRAP >> function# 0x176 >> ----- >>> >>> Having at least one LGTM for this case would be nice. >>> >>> >>> Thanks. >>> >>>> >>>>> MACH_VARS >>>>> If the argument >>>>> *length* is non-zero, the argument *buf* is the real address >>>>> of a data buffer, which must be aligned to the buffer size next >>>>> highest >>>>> power of two, (eg, if the buffer length is 500, the buffer address >>>>> must be >>>>> aligned on a 512-byte boundary). >>>> >>>> And this as well. >>>> >>>>> of a data buffer, which must be aligned to the buffer size next >>>>> highest >>>>> power of two, (eg, if the buffer length is 500, the buffer address >>>>> must be >>>>> aligned on a 512-byte boundary). >>>> >>>> And this as well. >>>> >>>>> If the argument *len* is non-zero, the argument *buf* is the real >>>>> address of a *len* sized data buffer, and must be aligned to the >>>>> buffer >>>>> size next highest power of two, (eg, if the buffer length is 500, >>>>> the buffer >>>>> address must be aligned on a 512-byte boundary). >>>> >>>> And this as well. >>>> >>>> Cheers!greg >>>> >>> >>> >> >> > > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu