From sacadmin Wed Mar 16 21:27:49 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2H5RnSp017649 for ; Wed, 16 Mar 2005 21:27:49 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2H5QIAH029557; Wed, 16 Mar 2005 21:26:18 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j2H5QGha085531; Wed, 16 Mar 2005 21:26:17 -0800 (PST) Message-ID: <423914F8.1080608@sun.com> Date: Wed, 16 Mar 2005 21:26:16 -0800 From: David Kahn User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FWARC@sac.sfbay.sun.com CC: David Redman , sun4v-iteam@sun.com Subject: FWARC/2005/173 - Hypervisor Service API Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 819 I'm sponsoring this case as a fast-track for David Redman. The fast-track timeout is March 23, 2005 This case defines an optional set of HV APIs. This optional set of APIs defines the data link layer transport of a pair of communication endpoints. The APIs are hardware independent. Also included is a set of machine description nodes and properties required to define service endpoints, and some binding information for those service endpoints. The specification is in the materials subdir of the case dir. The requested binding is minor release, the committment level of all interfaces is Sun Private. This case reserves FAST TRAP (0x80) function numbers 0x80 .. 0x84 for the APIs defined by the case, and these FAST TRAP function numbers should be documented in the registry being created by 2005/116. -David From sacadmin Thu Mar 17 11:35:48 2005 Received: from phys-san-2 (phys-san-2.West.Sun.COM [129.153.85.71]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2HJZmSp029999 for ; Thu, 17 Mar 2005 11:35:48 -0800 (PST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDI00K01GH1SZ@san-mail1.west.sun.com> (original mail from hitendra.zhangada@sun.com) for FWARC@sac.sfbay.sun.com; Thu, 17 Mar 2005 11:34:17 -0800 (PST) Received: from [129.153.85.35] (sr1-usan-05.West.Sun.COM [129.153.85.35]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDI00NJAH1453@san-mail1.west.sun.com>; Thu, 17 Mar 2005 11:34:17 -0800 (PST) Date: Thu, 17 Mar 2005 11:34:16 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2005/173 - Hypervisor Service API In-reply-to: <423914F8.1080608@sun.com> To: FWARC@sac.sfbay.sun.com Cc: sun4v-iteam@sun.com Reply-to: hitendra.zhangada@sun.com Message-id: <4239DBB8.9000607@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.6) Gecko/20050310 References: <423914F8.1080608@sun.com> Status: RO Content-Length: 3333 David Kahn wrote: > > I'm sponsoring this case as a fast-track for David Redman. > The fast-track timeout is March 23, 2005 I was going to send my comments to Dave Redman today but since this case is already submitted I am sending comments using the case number to everyone. Some of my comments are probably result of me not familiar with the machine descriptor case. I am going to review the machine descriptor case soon. I reviewed this case as a higher priority because David Redman, and others specifically asked me to review it. General comments : 0. Goes without saying but the new APIs will need to be added to the registry. I think the core API case should create the registry ASAP. 1. This case seems to be dependent upon the FWARC/2005/115 which defines the machine description and also core APIs case. I have not reviewed 2005/115 and hence I am having little hard time understanding some of the details in this fast-track case. This tells me that one can not review (or may be approve) this case until the other case is reviewed. I think the approval of this case may depend upon the changes that may be result from the review of 2005/115 case. Hopefully, 2005/115 goes through with very few changes in it. 2. From the service API spec it self it is not clear how one gets the SID. Is this part of machine descriptor? If so then please clarify this in section 2.2. 3. The MTU seems to be associated with SID as per section 3.1.2. Are MTU also part of machine descriptor? This can also be clarified in section 2.2. 4. What OBP virtual devices uses the SVC APIs? NVRAM is one of them, are there any other? I am assuming that the device bindings for NVRAM and other virtual devices using SVC APIs will be submitted to ARCs for review in future. Comments specific to various sections in the specification. 5. Section 3.2.2, I am little confused with the statement, "this is write-1-set operation". As per table in section 2.3, bits 1, 2 and 15 are write-1-clear. So, what happens if someone tries to "set" these bits. Is this an error? 6. Section 3.2.3, similar confusion with respect to the statement "this is a write-1-clear operation". Again as per table in section 2.3, there are bits which are not w1c. What happens to this bits when someone tries to write 1 using the svc_clrstatus API? 7. Section 4.1.1, what are "back" and "fwd" properties? I have a feeling that these are defined in the machine descriptor case. 8. Section 5.1.1, typo in the description of "reg" property. The "identity" is misspelled as "identify". 9. Section 6, nit, the state diagram is good but got me confused with the "svc_clrstatus, Clear RX bit" action in the lower right corner. It would have been clearer if this was to the right of the circular arrow going up to the first circle "Ready to RCV". I am going to review the machine descriptor case and if I have more comments after I review it then I will send them out. Thanks. -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Scalable Systems Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Thu Mar 17 12:47:58 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2HKlwSp004674 for ; Thu, 17 Mar 2005 12:47:58 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2HKkRjg005852; Thu, 17 Mar 2005 12:46:27 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j2HKkQha019641; Thu, 17 Mar 2005 12:46:26 -0800 (PST) Message-ID: <4239ECA1.9060608@sun.com> Date: Thu, 17 Mar 2005 12:46:25 -0800 From: David Kahn User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hitendra Zhangada CC: FWARC@sac.sfbay.sun.com, sun4v-iteam@sun.com Subject: Re: FWARC/2005/173 - Hypervisor Service API Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3658 Hitendra Zhangada wrote: > 0. Goes without saying but the new APIs will need to be added > to the registry. Yes, and I said that in the mail announcing the case. > > 1. This case seems to be dependent upon the FWARC/2005/115 > which defines the machine description and also core APIs case. > I have not reviewed 2005/115 and hence I am having little hard > time understanding some of the details in this fast-track case. > This tells me that one can not review (or may be approve) this > case until the other case is reviewed. > > I think the approval of this case may depend upon the changes > that may be result from the review of 2005/115 case. Hopefully, > 2005/115 goes through with very few changes in it. The machine description section of the document and the device template are effectively informative text in this case. They describe how the information is provided to the guest. > > 2. From the service API spec it self it is not clear how one gets > the SID. Is this part of machine descriptor? If so then please > clarify this in section 2.2. 4.1.2, sid property. sid is just an opaque 'handle'. 5.1.1, sid property. (derived from the md sid property in 4.1.2) > > 3. The MTU seems to be associated with SID as per section 3.1.2. > Are MTU also part of machine descriptor? This can also be > clarified in section 2.2. 4.1.2, mtu property. 5.1.1. mtu property (derived from the md mtu property in 4.1.2) > > 4. What OBP virtual devices uses the SVC APIs? NVRAM is one > of them, are there any other? I am assuming that the device > bindings for NVRAM and other virtual devices using SVC APIs > will be submitted to ARCs for review in future. This case exports the interfaces to use for obp, etc., and the example nodes are specified. Why would we need another case here, Hitendra? That would be overkill in my opinion. (It's up to the platform and implementation how it uses this stuff and what it uses it for.) The informative examples of the md, device node template, etc should be sufficient here. > > Comments specific to various sections in the specification. > > 5. Section 3.2.2, I am little confused with the statement, > "this is write-1-set operation". As per table in section > 2.3, bits 1, 2 and 15 are write-1-clear. So, what happens > if someone tries to "set" these bits. Is this an error? I think it ignores those bits. Dave should clarify this. > > 6. Section 3.2.3, similar confusion with respect to the statement > "this is a write-1-clear operation". Again as per table in > section 2.3, there are bits which are not w1c. What happens > to this bits when someone tries to write 1 using the > svc_clrstatus API? I think it ignores those bits. Dave should clarify this. > > 7. Section 4.1.1, what are "back" and "fwd" properties? I have > a feeling that these are defined in the machine descriptor case. back and fwd should be removed from this doc. (my opinion). They aren't required to describe the required properties for a service endpoint. > > 8. Section 5.1.1, typo in the description of "reg" property. > The "identity" is misspelled as "identify". > > 9. Section 6, nit, the state diagram is good but got me confused > with the "svc_clrstatus, Clear RX bit" action in the lower right > corner. It would have been clearer if this was to the right of > the circular arrow going up to the first circle "Ready to RCV". You're kidding right? I helped Dave with the state diagram. When I move the text up, it screws up the dotted line going to the TX side. From sacadmin Thu Mar 17 13:48:51 2005 Received: from phys-san-2 (phys-san-2.West.Sun.COM [129.153.85.71]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2HLmoSp011870 for ; Thu, 17 Mar 2005 13:48:50 -0800 (PST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDI00B01MNATX@san-mail1.west.sun.com> (original mail from hitendra.zhangada@sun.com) for FWARC@sac.sfbay.sun.com; Thu, 17 Mar 2005 13:47:16 -0800 (PST) Received: from [129.153.85.35] (sr1-usan-05.West.Sun.COM [129.153.85.35]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDI00NHDN6R53@san-mail1.west.sun.com>; Thu, 17 Mar 2005 13:47:16 -0800 (PST) Date: Thu, 17 Mar 2005 13:47:15 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2005/173 - Hypervisor Service API In-reply-to: <4239ECA1.9060608@sun.com> To: FWARC@sac.sfbay.sun.com Cc: sun4v-iteam@sun.com Reply-to: hitendra.zhangada@sun.com Message-id: <4239FAE3.6010506@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.6) Gecko/20050310 References: <4239ECA1.9060608@sun.com> Status: RO Content-Length: 5499 David Kahn wrote: > >> 1. This case seems to be dependent upon the FWARC/2005/115 >> which defines the machine description and also core APIs case. >> I have not reviewed 2005/115 and hence I am having little hard >> time understanding some of the details in this fast-track case. >> This tells me that one can not review (or may be approve) this >> case until the other case is reviewed. >> >> I think the approval of this case may depend upon the changes >> that may be result from the review of 2005/115 case. Hopefully, >> 2005/115 goes through with very few changes in it. > > > The machine description section of the document and the device template > are effectively informative text in this case. They describe how the > information is provided to the guest. > I understand that the spec is describing the APIs and how it gets various values etc. are defined else where and hence informative but I am little confused about the device template. Are you referring to section 5? If so then I thought section 5 is part of this case and it actually defines the properties for virtual devices which uses service APIs. Thus, section 5 can not be an informative section. >> >> 2. From the service API spec it self it is not clear how one gets >> the SID. Is this part of machine descriptor? If so then please >> clarify this in section 2.2. > > > 4.1.2, sid property. sid is just an opaque 'handle'. > 5.1.1, sid property. (derived from the md sid property in 4.1.2) > >> >> 3. The MTU seems to be associated with SID as per section 3.1.2. >> Are MTU also part of machine descriptor? This can also be >> clarified in section 2.2. > > > 4.1.2, mtu property. > 5.1.1. mtu property (derived from the md mtu property in 4.1.2) What I am suggesting it that clarity in section 2.2 will be helpful since SID as an argument is used in sections prior to 4.1.2. Note that I was asked by Dave to comment on his specification yesterday. And these are my suggestions only. I am not insisting on these changes. > >> >> 4. What OBP virtual devices uses the SVC APIs? NVRAM is one >> of them, are there any other? I am assuming that the device >> bindings for NVRAM and other virtual devices using SVC APIs >> will be submitted to ARCs for review in future. > > > This case exports the interfaces to use for obp, etc., and the example > nodes are specified. Why would we need another case here, Hitendra? Where are the example nodes specified? I only see mention of NVRAM. > That would be overkill in my opinion. (It's up to the platform and > implementation how it uses this stuff and what it uses it for.) > The informative examples of the md, device node template, etc > should be sufficient here. The section 5, first paragraph states that "the property values are all extracted from the MD, and nodes are created under the /virtual-devices node for each platform_service found in the Machine Description". So, isn't it true that each of the platform_service will have a corresponding OBP device node under /virtual-devices node? Each of these nodes will have unique "name" and "compatible" properties. Aren't the values of these two property need to be documented/reviewed? Is Solaris a consumer of these properties? I think answer is no, right? So, when platform implements these nodes, they do not have to submit a fast-track for it, right? I just want to be clear here. >> >> Comments specific to various sections in the specification. >> >> 5. Section 3.2.2, I am little confused with the statement, >> "this is write-1-set operation". As per table in section >> 2.3, bits 1, 2 and 15 are write-1-clear. So, what happens >> if someone tries to "set" these bits. Is this an error? > > > I think it ignores those bits. Dave should clarify this. > > >> >> 6. Section 3.2.3, similar confusion with respect to the statement >> "this is a write-1-clear operation". Again as per table in >> section 2.3, there are bits which are not w1c. What happens >> to this bits when someone tries to write 1 using the >> svc_clrstatus API? > > > I think it ignores those bits. Dave should clarify this. > >> >> 7. Section 4.1.1, what are "back" and "fwd" properties? I have >> a feeling that these are defined in the machine descriptor case. > > > back and fwd should be removed from this doc. (my opinion). They > aren't required to describe the required properties for a service > endpoint. > >> >> 8. Section 5.1.1, typo in the description of "reg" property. >> The "identity" is misspelled as "identify". >> >> 9. Section 6, nit, the state diagram is good but got me confused >> with the "svc_clrstatus, Clear RX bit" action in the lower right >> corner. It would have been clearer if this was to the right of >> the circular arrow going up to the first circle "Ready to RCV". > > > You're kidding right? I helped Dave with the state diagram. When I > move the text up, it screws up the dotted line going to the TX side. No I was not kidding. I noticed the dotted line but then I thought may be there is a way to have curved dotted line going to TX side. Anyway, this is just a nit for clarity. No changes are needed. -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Scalable Systems Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Sat Mar 19 17:21:21 2005 Received: from noho.SFBay.Sun.COM (noho [10.6.92.101]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2K1LKSp027021 for ; Sat, 19 Mar 2005 17:21:21 -0800 (PST) Received: from noho.SFBay.Sun.COM (localhost [127.0.0.1]) by noho.SFBay.Sun.COM (8.13.0+Sun/8.13.0) with ESMTP id j2K1JmFD008989; Sat, 19 Mar 2005 17:19:48 -0800 (PST) Received: (from dmk@localhost) by noho.SFBay.Sun.COM (8.13.0+Sun/8.13.0/Submit) id j2K1JmHN008988; Sat, 19 Mar 2005 17:19:48 -0800 (PST) Date: Sat, 19 Mar 2005 17:19:48 -0800 (PST) From: David Kahn Message-Id: <200503200119.j2K1JmHN008988@noho.SFBay.Sun.COM> To: FWARC@sac.sfbay.sun.com Subject: Re: FWARC/2005/173 - Hypervisor Service API Cc: David.Redman@sun.com, sun4v-iteam@sun.com Status: RO Content-Length: 371 There's a new version (0.44) of the spec in the materials directory addressing most of Hitendra's questions. Added fwd reference to 4.1.1 in section 2 for MTU and SID sources. Clarified that set/clrstatus only affects bits that can be cleared or set. Added section 5.2, describing specific nodes on Great Lakes platforms. The timeout is unchanged (March 23) -David From sacadmin Tue Mar 22 10:50:29 2005 Received: from phys-san-2 (phys-san-2.West.Sun.COM [129.153.85.71]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2MIoSSp026556 for ; Tue, 22 Mar 2005 10:50:29 -0800 (PST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDR00501NTBFU@san-mail1.west.sun.com> (original mail from hitendra.zhangada@sun.com) for FWARC@sac.sfbay.sun.com; Tue, 22 Mar 2005 10:48:50 -0800 (PST) Received: from [129.153.85.35] (sr1-usan-05.West.Sun.COM [129.153.85.35]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDR0014DO9DVL@san-mail1.west.sun.com>; Tue, 22 Mar 2005 10:48:50 -0800 (PST) Date: Tue, 22 Mar 2005 10:48:49 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2005/173 - Hypervisor Service API In-reply-to: <200503200119.j2K1JmHN008988@noho.SFBay.Sun.COM> To: FWARC@sac.sfbay.sun.com Cc: sun4v-iteam@sun.com Reply-to: hitendra.zhangada@sun.com Message-id: <42406891.6090105@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.6) Gecko/20050310 References: <200503200119.j2K1JmHN008988@noho.SFBay.Sun.COM> Status: RO Content-Length: 1831 David Kahn wrote: > There's a new version (0.44) of the spec in > the materials directory addressing most of > Hitendra's questions. > > Added fwd reference to 4.1.1 in section 2 > for MTU and SID sources. > > Clarified that set/clrstatus only affects bits > that can be cleared or set. Thanks a lot for above changes. > > Added section 5.2, describing specific nodes > on Great Lakes platforms. I noticed that the values for "compatible" property is missing from all of the tables in section 5.2. Does this mean there are no Solaris drivers loaded for any of these virtual device nodes and hence the compatible property is not created for these nodes? If "compatible" property is an optional property then I think that need to be made clear in section 5.1.1. Section 5.2.4 includes value for "device_type" property but the section 5.1 states that "device_type" property is not required for these nodes. Further, this property is not defined in section 5.1.1 which implies that this property is not needed. So, does NVRAM node really need "device_type" property? If it is needed then I suggest we change the last sentence of section 5.2 to, "Unless stated ..... no device methods or device_type property." And also change section 5.1 to that the "device_type" property or methods are not required for most nodes (instead of stating that these are not required, state that these are not required for most nodes). BTW, there is still a typo in the description of the "reg" property in the section 5.1.1, replace "identify" with "identity". > > The timeout is unchanged (March 23) > > -David > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Scalable Systems Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Tue Mar 22 15:01:04 2005 Received: from phys-hanwk-1 (phys-hanwk-1.SFBay.Sun.COM [129.149.2.111]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2MN14Sp026987 for ; Tue, 22 Mar 2005 15:01:04 -0800 (PST) Received: from conversion-daemon.hanwk-mail1.sfbay.sun.com by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDR00K01ZP11E@hanwk-mail1.sfbay.sun.com> (original mail from s.jain@sun.com) for FWARC@sac.sfbay.sun.com; Tue, 22 Mar 2005 14:59:30 -0800 (PST) Received: from sun.com (sr1-unwk20-07.SFBay.Sun.COM [129.149.2.108]) by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IDR00KKNZV4NX@hanwk-mail1.sfbay.sun.com>; Tue, 22 Mar 2005 14:59:28 -0800 (PST) Date: Tue, 22 Mar 2005 14:59:28 -0800 From: sunit jain Subject: Re: FWARC/2005/173 - Hypervisor Service API In-reply-to: <42406891.6090105@sun.com> Cc: FWARC@sac.sfbay.sun.com, sun4v-iteam@sun.com Reply-to: S.Jain@Sun.COM Message-id: <4240A350.3030309@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 References: <200503200119.j2K1JmHN008988@noho.SFBay.Sun.COM> <42406891.6090105@sun.com> Status: RO Content-Length: 1284 I have couple of question related to the "seek" method defined in section 5.2.4 Page 11. svcapi document defines "seek" method as: seek ( offset type -- fail? ) which is not standard/1275 "seek" method { seek ( hi lo -- fail? ) } while the svcapi document says that the methods are "standard" methods used by OBP 4.x. Also, the description of 'type' parameter is a bit confusing. Is the following correct? * When type=0, offset can be 0..N (all positive, N is the device size). * When type=1, offset can be either positive or negative. * Document says that for type 0 & 2, offset is positive, but for type=2 isn't the offset going from high to low? Offset should be negative in the type=2 case? Regards, Sunit -- ..................................................................... _/_/_/ _/ _/ _/ _/ Sunit Jain _/ _/ _/ _/_/ _/ Sun Microsystems, Inc. _/_/_/ _/ _/ _/ _/ _/ 7788 Gateway Blvd., Building 20 _/ _/ _/ _/ _/_/ Mailstop UNWK20-210 _/_/_/ _/_/_/ _/ _/ Newark, CA 94560 Phone/fax - 510-996-7099 M I C R O S Y S T E M S Internal - x31726 ..................................................................... From sacadmin Tue Mar 22 15:29:15 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2MNTFSp028117 for ; Tue, 22 Mar 2005 15:29:15 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2MNRfAH004251; Tue, 22 Mar 2005 15:27:41 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j2MNRdha050817; Tue, 22 Mar 2005 15:27:40 -0800 (PST) Message-ID: <4240A9EA.9020603@sun.com> Date: Tue, 22 Mar 2005 15:27:38 -0800 From: David Kahn User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hitendra Zhangada CC: FWARC@sac.sfbay.sun.com, sun4v-iteam@sun.com Subject: Re: FWARC/2005/173 - Hypervisor Service API Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 805 Hitendra Zhangada wrote: > I noticed that the values for "compatible" property is missing > from all of the tables in section 5.2. Does this mean there are > no Solaris drivers loaded for any of these virtual device nodes > and hence the compatible property is not created for these nodes? "compatible" is optional. > Section 5.2.4 includes value for "device_type" property but the > section 5.1 states that "device_type" property is not required > for these nodes. Further, this property is not defined in section > 5.1.1 which implies that this property is not needed. It isn't required. It's optional. The detailed description of the "nvram" node, which is the only node with methods, has a "device_type" which describes how that package works. This is pretty much standard OBP stuff. -David From sacadmin Wed Mar 23 17:29:20 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2O1TJSp003044 for ; Wed, 23 Mar 2005 17:29:20 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2O1RiAH024082; Wed, 23 Mar 2005 17:27:44 -0800 (PST) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id j2O1Rgha020194; Wed, 23 Mar 2005 17:27:43 -0800 (PST) Message-ID: <4242178E.4080903@sun.com> Date: Wed, 23 Mar 2005 17:27:42 -0800 From: David Kahn User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FWARC@sac.sfbay.sun.com CC: sun4v-iteam@sun.com, sunit jain , Hitendra Zhangada Subject: FWARC/2005/173 - Hypervisor Service API Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2018 There's a new version of the spec (0.45) in the materials directory. Changes are listed below. Hitendra Zhangada wrote: > If "compatible" property is an optional property then I think > that need to be made clear in section 5.1.1. Added "note" to 5.1.1 > > Section 5.2.4 includes value for "device_type" property but the > section 5.1 states that "device_type" property is not required > for these nodes. Further, this property is not defined in section > 5.1.1 which implies that this property is not needed. > > So, does NVRAM node really need "device_type" property? If it is > needed then I suggest we change the last sentence of section 5.2 > to, "Unless stated ..... no device methods or device_type property." > And also change section 5.1 to that the "device_type" property or > methods are not required for most nodes (instead of stating that > these are not required, state that these are not required for most > nodes). Made the suggested changes. > > BTW, there is still a typo in the description of the "reg" property > in the section 5.1.1, replace "identify" with "identity". Deleted the extra text in "reg". It isn't needed and that also takes care of the typo and wording there. sunit jain wrote: > I have couple of question related to the "seek" method defined in > section 5.2.4 Page 11. > Also, the description of 'type' parameter is a bit confusing. Is the > following correct? > > * When type=0, offset can be 0..N (all positive, N is the device size). > > * When type=1, offset can be either positive or negative. > > * Document says that for type 0 & 2, offset is positive, but for type=2 > isn't the offset going from high to low? Offset should be negative in > the type=2 case? Dave and I cleaned that up. Type 2 isn't supported by this package. Use of type 2 results in an error. For type 0 (seek from beginning of device) offset must be zero or a positive value. For type 1 (seek relative to current position) offset may be zero, positive or negative. -David From sacadmin Wed Mar 23 21:40:11 2005 Received: from phys-san-2 (phys-san-2.West.Sun.COM [129.153.85.71]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2O5eBSp016556 for ; Wed, 23 Mar 2005 21:40:11 -0800 (PST) Received: from conversion-daemon.san-mail1.west.sun.com by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDU00A01CY67Z@san-mail1.west.sun.com> (original mail from Hitendra.Zhangada@sun.com) for FWARC@sac.sfbay.sun.com; Wed, 23 Mar 2005 21:38:36 -0800 (PST) Received: from [129.150.112.74] (vpn-129-150-112-74.Holland.Sun.COM [129.150.112.74]) by san-mail1.west.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDU009EGD085S@san-mail1.west.sun.com>; Wed, 23 Mar 2005 21:38:36 -0800 (PST) Date: Wed, 23 Mar 2005 21:38:32 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2005/173 - Hypervisor Service API In-reply-to: <4242178E.4080903@sun.com> To: FWARC@sac.sfbay.sun.com Cc: sun4v-iteam@sun.com, sunit jain Message-id: <42425258.6020304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <4242178E.4080903@sun.com> Status: RO Content-Length: 2441 David Kahn wrote: > > > There's a new version of the spec (0.45) in > the materials directory. > > Changes are listed below. Thanks a lot for the changes. I am happy now :) > > > Hitendra Zhangada wrote: > >> If "compatible" property is an optional property then I think >> that need to be made clear in section 5.1.1. > > > Added "note" to 5.1.1 > >> >> Section 5.2.4 includes value for "device_type" property but the >> section 5.1 states that "device_type" property is not required >> for these nodes. Further, this property is not defined in section >> 5.1.1 which implies that this property is not needed. >> >> So, does NVRAM node really need "device_type" property? If it is >> needed then I suggest we change the last sentence of section 5.2 >> to, "Unless stated ..... no device methods or device_type property." >> And also change section 5.1 to that the "device_type" property or >> methods are not required for most nodes (instead of stating that >> these are not required, state that these are not required for most >> nodes). > > > Made the suggested changes. > >> >> BTW, there is still a typo in the description of the "reg" property >> in the section 5.1.1, replace "identify" with "identity". > > > Deleted the extra text in "reg". It isn't needed and that also > takes care of the typo and wording there. > > > > sunit jain wrote: > >> I have couple of question related to the "seek" method defined in >> section 5.2.4 Page 11. > > >> Also, the description of 'type' parameter is a bit confusing. Is the >> following correct? >> >> * When type=0, offset can be 0..N (all positive, N is the device size). >> >> * When type=1, offset can be either positive or negative. >> >> * Document says that for type 0 & 2, offset is positive, but for type=2 >> isn't the offset going from high to low? Offset should be negative in >> the type=2 case? > > > Dave and I cleaned that up. > > Type 2 isn't supported by this package. Use of type 2 results > in an error. > > For type 0 (seek from beginning of device) offset must be zero or > a positive value. > > For type 1 (seek relative to current position) offset may be zero, > positive or negative. > > -David > > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Scalable Systems Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Thu Mar 24 20:25:22 2005 Received: from noho.SFBay.Sun.COM (noho [10.6.92.101]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2P4PMSp017200 for ; Thu, 24 Mar 2005 20:25:22 -0800 (PST) Received: from noho.SFBay.Sun.COM (localhost [127.0.0.1]) by noho.SFBay.Sun.COM (8.13.0+Sun/8.13.0) with ESMTP id j2P4NkJD011102; Thu, 24 Mar 2005 20:23:46 -0800 (PST) Received: (from dmk@localhost) by noho.SFBay.Sun.COM (8.13.0+Sun/8.13.0/Submit) id j2P4NkTu011101; Thu, 24 Mar 2005 20:23:46 -0800 (PST) Date: Thu, 24 Mar 2005 20:23:46 -0800 (PST) From: David Kahn Message-Id: <200503250423.j2P4NkTu011101@noho.SFBay.Sun.COM> To: FWARC@sac.sfbay.sun.com Subject: Re: FWARC/2005/173 - Hypervisor Service API Cc: hitendra.zhangada@sun.com, s.jain@sun.com, sun4v-iteam@sun.com Status: RO Content-Length: 199 This case is now approved for integration into a minor release of the firmware and a micro release of the OS. All interfaces are "Sun Private". The HV APIs have been added to the registry. -David From sacadmin Fri Mar 25 15:07:18 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j2PN7ISp015216 for ; Fri, 25 Mar 2005 15:07:18 -0800 (PST) Received: from noho.SFBay.Sun.COM (noho.SFBay.Sun.COM [10.6.92.101]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j2PN5fZ27188 for ; Fri, 25 Mar 2005 15:05:41 -0800 (PST) Received: from noho.SFBay.Sun.COM (localhost [127.0.0.1]) by noho.SFBay.Sun.COM (8.13.0+Sun/8.13.0) with ESMTP id j2PN5eh8011516 for ; Fri, 25 Mar 2005 15:05:40 -0800 (PST) Received: (from dmk@localhost) by noho.SFBay.Sun.COM (8.13.0+Sun/8.13.0/Submit) id j2PN5ehd011515 for fwarc-record@sun.com; Fri, 25 Mar 2005 15:05:40 -0800 (PST) Date: Fri, 25 Mar 2005 15:05:40 -0800 (PST) From: David Kahn Message-Id: <200503252305.j2PN5ehd011515@noho.SFBay.Sun.COM> To: fwarc-record@sun.com Subject: Re: FWARC/2005/173 - Hypervisor Service API Status: RO Content-Length: 567 >From sacadmin Thu Mar 24 20:25:22 2005 >Date: Thu, 24 Mar 2005 20:23:46 -0800 (PST) >From: David Kahn >To: FWARC@sac.sfbay.sun.com >Subject: Re: FWARC/2005/173 - Hypervisor Service API >Cc: hitendra.zhangada@sun.com, s.jain@sun.com, sun4v-iteam@sun.com > >This case is now approved for integration into >a minor release of the firmware and a micro release >of the OS. All interfaces are "Sun Private". Correction: This case is now approved for integration into a minor release of the firmware and a micro/patch release of the OS. -David