From sacadmin Fri Jan 27 21:11:31 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0S5BUIQ016007 for ; Fri, 27 Jan 2006 21:11:31 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k0S5BQJA004189; Sat, 28 Jan 2006 13:11:27 +0800 (SGT) 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 <0ITS00K01EF2YJ00@brm-avmta-1.central.sun.com>; Fri, 27 Jan 2006 22:11:26 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITS004U7EF20880@brm-avmta-1.central.sun.com>; Fri, 27 Jan 2006 22:11:26 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k0S5BP8u004623; Fri, 27 Jan 2006 22:11:26 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ITS00301EDI0W00@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM); Fri, 27 Jan 2006 22:11:25 -0700 (MST) Received: from sun.com ([129.150.32.29]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ITS007EEEF0WS30@mail-amer.sun.com>; Fri, 27 Jan 2006 22:11:25 -0700 (MST) Date: Fri, 27 Jan 2006 21:11:26 -0800 From: Tony Sumpter Subject: FWARC/2006/052 sun4v version API update [fast-track] Sender: Tony.Sumpter@sun.com To: fwarc@sun.com Cc: pq-arch@sun.com, Richard Barnette Message-id: <43DAFCFE.9080506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.1.222179 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 2566 I'm sponsoring this case as a fast-track for Ashley Saulsbury. The fast-track timeout is Feb 3, 2006. The materials are in the case directory under 'materials': http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/ The normative text in api-26-v6-ver.pdf is in sections 9.1.1 (other than the reference to 'Appendix B' and the Programming note) and 9.1.2. The Programming note and section 9.1.1.2 are informative. The case updates the HV APIs for API versioning approved in FWARC/2006/499 in the following ways: Major number 0 (zero) is reserved to have a special behavior for api_set_version: the API groups is returned to the initial un-negotiated state. The effect of a re-negotiation concurrent with use of the API group is defined. The addition of the EWOULDBLOCK to 9.1.1.1 (not in the supplied materials) to indicate that the api_set_version call could not complete without blocking. The API group number table is removed and initial group assignments and requirements for future cases are set out below. All other aspects of the APIs defined in FWARC/2005/499 remain the same. After approval of this case: 1) Future API cases must specify API group numbers and version number for each function created or changed. 2) Assignment of an API group number will not require a separate case from the APIs defined in it. 3) The group and version numbers will be entered into the API registry with the function numbers on case approval. 4) The registry format will change to accommodate the additional information and the existing registry will be updated to the new format using the API group and version number data provided in the file api-26-v6-reg.pdf in the materials directory. This document implies that some interpretation of group and function numbers may be performed (eg function numbers of the form 0x0## are core or 0x1## are platform specific): these are NOT interfaces and the choice of ranges is purely for mnemonic and decoding convenience. The following is a excerpt of the new registry format: Trap# Func# Group# Vers# Case# Comments ===== ===== ====== ===== ===== ======== 0x80 -- N/A N/A FWARC/2005/116 FAST_TRAP 0x83 -- 0x001 1.0 FWARC/2005/116 MMU_MAP_ADDR 0x84 -- 0x001 1.0 FWARC/2005/116 MMU_UNMAP_ADDR 0x85 -- 0x001 1.0 FWARC/2005/116 TTRACE_ADDENTRY 0xff -- N/A N/A FWARC/2005/116 CORE_TRAP 0x80 0x00 0x001 1.0 FWARC/2005/116 MACH_EXIT 0x80 0x01 0x001 1.0 FWARC/2005/116 MACH_DESC Note that no separate table of groups is proposed since a group number cannot be assigned on its own. Tony. From sacadmin Thu Feb 2 11:48:48 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k12JmmIQ017410 for ; Thu, 2 Feb 2006 11:48:48 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k12Jmlr02345; Thu, 2 Feb 2006 11:48:47 -0800 (PST) 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 <0IU200L03SD90G00@brm-avmta-1.central.sun.com>; Thu, 02 Feb 2006 12:48:45 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IU200D9FSD9ZLB0@brm-avmta-1.central.sun.com>; Thu, 02 Feb 2006 12:48:45 -0700 (MST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k12Jmjuf008393; Thu, 02 Feb 2006 12:48:45 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IU200801RTYGC00@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM); Thu, 02 Feb 2006 12:48:45 -0700 (MST) Received: from sun.com ([129.150.25.137]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IU200JO5SD3SI40@mail-amer.sun.com>; Thu, 02 Feb 2006 12:48:44 -0700 (MST) Date: Thu, 02 Feb 2006 11:48:39 -0800 From: Tony Sumpter Subject: Re: FWARC/2006/052 sun4v version API update [fast-track] In-reply-to: <43DAFCFE.9080506@sun.com> Sender: Tony.Sumpter@Sun.COM To: fwarc@Sun.COM Cc: pq-arch@Sun.COM, Richard Barnette Message-id: <43E26217.90504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 References: <43DAFCFE.9080506@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 3604 I have changed the status of this case to 'waiting needs spec' while some questions are resolved. The questions have been phrased in the form of a FAQ and updates are in progress - see http://cpubringup.sfbay.sun.com/twiki/bin/view/Hypervisor/HypervisorAPIVersionFAQ I have also deposited a minor update to api-26-v6-ver.pdf in the materials directory that has EWOULDBLOCK in the list of errors. Note that when this case restarts, the OBP CIF interface to the HV API will be either be added or submitted as a separate case. This CIF interface is a requirement for the Solaris version services listed in case PSARC/2006/029 - see http://sac.eng/arc/PSARC/2006/029/ Tony. Tony Sumpter wrote: > I'm sponsoring this case as a fast-track for Ashley Saulsbury. > The fast-track timeout is Feb 3, 2006. > > The materials are in the case directory under 'materials': > http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/ > The normative text in api-26-v6-ver.pdf is in sections 9.1.1 (other than > the reference to 'Appendix B' and the Programming > note) and 9.1.2. The Programming note and section 9.1.1.2 are > informative. > > The case updates the HV APIs for API versioning approved in > FWARC/2006/499 in the following ways: > > Major number 0 (zero) is reserved to have a special behavior > for api_set_version: the API groups is returned to the initial > un-negotiated state. > > The effect of a re-negotiation concurrent with use of the > API group is defined. > > The addition of the EWOULDBLOCK to 9.1.1.1 (not in the > supplied materials) to indicate that the api_set_version > call could not complete without blocking. > > The API group number table is removed and initial group assignments > and requirements for future cases are set out below. > > All other aspects of the APIs defined in FWARC/2005/499 remain the > same. > > After approval of this case: > > 1) Future API cases must specify API group numbers and version number > for each function created or changed. > > 2) Assignment of an API group number will not require a separate > case from the APIs defined in it. > > 3) The group and version numbers will be entered into the API registry > with the function numbers on case approval. > > 4) The registry format will change to accommodate the > additional information and the existing registry will be updated > to the new format using the API group and version number data > provided in the file api-26-v6-reg.pdf in the materials directory. > This document implies that some interpretation of group and function > numbers may be performed (eg function numbers of the form 0x0## are > core or 0x1## are platform specific): these are NOT interfaces and the > choice of ranges is purely for mnemonic and decoding convenience. > > The following is a excerpt of the new registry format: > > Trap# Func# Group# Vers# Case# Comments > ===== ===== ====== ===== ===== ======== > > 0x80 -- N/A N/A FWARC/2005/116 FAST_TRAP > 0x83 -- 0x001 1.0 FWARC/2005/116 MMU_MAP_ADDR > 0x84 -- 0x001 1.0 FWARC/2005/116 MMU_UNMAP_ADDR > 0x85 -- 0x001 1.0 FWARC/2005/116 TTRACE_ADDENTRY > 0xff -- N/A N/A FWARC/2005/116 CORE_TRAP > > > 0x80 0x00 0x001 1.0 FWARC/2005/116 MACH_EXIT > 0x80 0x01 0x001 1.0 FWARC/2005/116 MACH_DESC > > Note that no separate table of groups is proposed since a group number > cannot be assigned on its own. > > Tony. > > From sacadmin Mon Feb 6 11:54:37 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k16JsaIQ024752 for ; Mon, 6 Feb 2006 11:54:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k16JsU53017773; Tue, 7 Feb 2006 03:54:35 +0800 (SGT) 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 <0IUA00D017AZUK00@brm-avmta-1.central.sun.com>; Mon, 06 Feb 2006 12:54:35 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUA006O47AYG0D0@brm-avmta-1.central.sun.com>; Mon, 06 Feb 2006 12:54:35 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k16JsYTe016207; Mon, 06 Feb 2006 11:54:34 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k16JsUIQ024715; Mon, 06 Feb 2006 11:54:30 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id k16JsUkq024714; Mon, 06 Feb 2006 11:54:30 -0800 (PST) Date: Mon, 06 Feb 2006 11:54:30 -0800 (PST) From: FWARC-coord@sun.com Subject: New FWARC Materials Submitted 2006/052 sun4v version API update To: FWARC@sun.com Cc: Ashley.Saulsbury@sun.com, FWARC-coord@sun.com Message-id: <200602061954.k16JsUkq024714@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 360 New Materials submitted for FWARC 2006/052 sun4v version API update Status: waiting need spec 02/02/2006 Files: /shared/sac/FWARC/2006/052/inception.materials/api-26-v6-reg.pdf /shared/sac/FWARC/2006/052/inception.materials/api-26-v6-ver.pdf /shared/sac/FWARC/2006/052/inception.materials/versions-cif.txt Please let me know if you have questions. - FWARC From sacadmin Fri Feb 10 08:20:40 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1AGKeIQ004280 for ; Fri, 10 Feb 2006 08:20:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1AGKcB14799; Fri, 10 Feb 2006 08:20:38 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IUH00G03C29AR00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 10 Feb 2006 08:20:33 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IUH0035IC2998I0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 10 Feb 2006 08:20:33 -0800 (PST) Received: from d1-sfbay-02.sun.com ([192.18.39.112]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id k1AGKXVs002583; Fri, 10 Feb 2006 08:20:33 -0800 (PST) Received: from conversion-daemon.d1-sfbay-02.sun.com by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IUH00B016TX3J00@d1-sfbay-02.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Fri, 10 Feb 2006 08:20:33 -0800 (PST) Received: from [129.150.34.10] by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IUH00BMGC28QZ10@d1-sfbay-02.sun.com>; Fri, 10 Feb 2006 08:20:33 -0800 (PST) Date: Fri, 10 Feb 2006 08:20:35 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2006/052 sun4v version API update [fast-track] In-reply-to: <43E26217.90504@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: fwarc@Sun.COM Cc: pq-arch@Sun.COM, Richard Barnette , Ashley Saulsbury Message-id: <43ECBD53.9070104@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 References: <43DAFCFE.9080506@sun.com> <43E26217.90504@sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) Status: RO Content-Length: 1757 I have couple of comments for this case. Is this case ready for review? The IAM file states 'waiting need spec'. It is ready but wants to confirm. Assuming that it is ready for review. I have following questions and comments. 1. Section 9.1.1, why are arg1 and arg2 not consistently labeled? Why is major_number not called req_major_number? or may be why not req_minor_number be called minor_number? 2. For the CIF document it is not clear the ordering of the output arguments. Since CIFs follow FORTH style the last argument is generally the top of stack. With this in mind what we have in the spec seems incorrect since the "status" is the generally on the top of stack. I suggest following changes to be consistent with FORTH style. Change, SUNW,set-sun4v-version IN: group, major, minor OUT: status, act-minor to, SUNW,set-sun4v-version ( group major minor -- act-minor status ) and also change, SUNW,get-sun4v-version IN: group OUT: status, major, minor to, SUNW,get-sun4v-version ( group -- major minor status ) May be the arguments in the original document is intentional (not having status on top of stack). Please clarify. I do see that the CIF is proposed to be consistent with the API call with respect to output arguments but I think in context of OpenBoot it seems the order is not correct. Does others have similar concerns? Thanks. -- 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 Mon Feb 13 08:44:05 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1DGi5IQ023968 for ; Mon, 13 Feb 2006 08:44:05 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1DGi4U06312; Mon, 13 Feb 2006 08:44:04 -0800 (PST) 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 <0IUM00L01X53J400@brm-avmta-1.central.sun.com>; Mon, 13 Feb 2006 09:43:51 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUM00IE0X518540@brm-avmta-1.central.sun.com>; Mon, 13 Feb 2006 09:43:49 -0700 (MST) Received: from phys-hanwk-1 (phys-hanwk-1.SFBay.Sun.COM [129.149.2.111]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1DGhnTe016177; Mon, 13 Feb 2006 08:43:49 -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 <0IUM00D01X2DR5@hanwk-mail1.sfbay.sun.com> (original mail from richard.barnette@sun.com); Mon, 13 Feb 2006 08:43:49 -0800 (PST) Received: from [192.168.1.102] (vpn-129-150-24-114.SFBay.Sun.COM [129.150.24.114]) by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IUM0008WX4Y46@hanwk-mail1.sfbay.sun.com>; Mon, 13 Feb 2006 08:43:47 -0800 (PST) Date: Mon, 13 Feb 2006 08:43:54 -0800 From: Richard Barnette Subject: Re: FWARC/2006/052 sun4v version API update [fast-track] In-reply-to: <43ECBD53.9070104@sun.com> To: pq-arch@sun.com, Firmware Arch Message-id: <6f7603372913b58f01d0ff62e087cfa4@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <43DAFCFE.9080506@sun.com> <43E26217.90504@sun.com> <43ECBD53.9070104@sun.com> Status: RO Content-Length: 2771 On Feb 10, 2006, at 8:20 AM, Hitendra Zhangada wrote: > I have couple of comments for this case. > > Is this case ready for review? The IAM file states > 'waiting need spec'. It is ready but wants to confirm. > Assuming that it is ready for review. I have following > questions and comments. > > > 1. Section 9.1.1, why are arg1 and arg2 not consistently > labeled? Why is major_number not called req_major_number? > or may be why not req_minor_number be called minor_number? > > 2. For the CIF document it is not clear the ordering of the > output arguments. Since CIFs follow FORTH style the last > argument is generally the top of stack. With this in mind > what we have in the spec seems incorrect since the "status" > is the generally on the top of stack. I suggest following > changes to be consistent with FORTH style. > OK. Seems I've misunderstood argument ordering conventions for CIF documentation. Just so there's no confusion, here's the standard stack notation on the API: SUNW,set-sun4v-version ( minor major group -- act-minor status ) SUNW,get-sun4v-version ( group -- minor major status ) This is the actual ordering in the implementation, and is characteristic of definitions created by hypercall: For my own sake, I need to go review a copy of IEEE1275. I'll try to get a corrected CIF out by end-of-day. Thanks! > Change, > SUNW,set-sun4v-version > IN: group, major, minor > OUT: status, act-minor > > to, > SUNW,set-sun4v-version ( group major minor -- act-minor status > ) > > and also change, > > SUNW,get-sun4v-version > IN: group > OUT: status, major, minor > to, > SUNW,get-sun4v-version ( group -- major minor status ) > > > May be the arguments in the original document is intentional (not > having status on top of stack). Please clarify. I do see that > the CIF > is proposed to be consistent with the API call with respect to > output > arguments but I think in context of OpenBoot it seems the order is > not correct. > > Does others have similar concerns? > > Thanks. > > -- > 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 > -- Richard Barnette | Belinda giggled till she shook the house, Sun Microsystems | And Blink said Weeck! which is giggling for a mouse, Supernova Software | Ink and Mustard rudely asked his age, NWK20 3168 / UNWK20-310 | When Custard cried for a nice safe cage. (510) 936-3986 / x13986 | - Ogden Nash, "The Tale of Custard the Dragon" From sacadmin Mon Feb 13 17:44:57 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1E1iuIQ018726 for ; Mon, 13 Feb 2006 17:44:56 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1E1itT02707; Mon, 13 Feb 2006 18:44:55 -0700 (MST) 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 <0IUN00K05M6UUP00@nwk-avmta-2.sfbay.sun.com>; Mon, 13 Feb 2006 17:44:54 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUN00A4DM6T9SC0@nwk-avmta-2.sfbay.sun.com>; Mon, 13 Feb 2006 17:44:53 -0800 (PST) Received: from phys-hanwk-1 (phys-hanwk-1.SFBay.Sun.COM [129.149.2.111]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1E1iqLp028750; Mon, 13 Feb 2006 17:44:53 -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 <0IUN00B01LTACN@hanwk-mail1.sfbay.sun.com> (original mail from richard.barnette@sun.com); Mon, 13 Feb 2006 17:44:53 -0800 (PST) Received: from [129.149.204.182] (d-nwk20-204-182.SFBay.Sun.COM [129.149.204.182]) by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IUN0076BM6S51@hanwk-mail1.sfbay.sun.com>; Mon, 13 Feb 2006 17:44:52 -0800 (PST) Date: Mon, 13 Feb 2006 17:45:01 -0800 From: Richard Barnette Subject: Re: FWARC/2006/052 sun4v version API update [fast-track] In-reply-to: <6f7603372913b58f01d0ff62e087cfa4@sun.com> To: pq-arch@Sun.COM, Firmware Arch Message-id: <4fe6ccfb94091ee2e58161675f35626c@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <43DAFCFE.9080506@sun.com> <43E26217.90504@sun.com> <43ECBD53.9070104@sun.com> <6f7603372913b58f01d0ff62e087cfa4@sun.com> Status: RO Content-Length: 2191 On Feb 13, 2006, at 8:43 AM, Richard Barnette wrote: [ ... ] >> 2. For the CIF document it is not clear the ordering of the >> output arguments. Since CIFs follow FORTH style the last >> argument is generally the top of stack. With this in mind >> what we have in the spec seems incorrect since the "status" >> is the generally on the top of stack. I suggest following >> changes to be consistent with FORTH style. >> > OK. Seems I've misunderstood argument ordering conventions > for CIF documentation. Just so there's no confusion, here's > the standard stack notation on the API: > SUNW,set-sun4v-version ( minor major group -- act-minor status ) > SUNW,get-sun4v-version ( group -- minor major status ) > > This is the actual ordering in the implementation, and is > characteristic of definitions created by hypercall: > Hitu, I went and reviewed the IEEE spec, and I think the ordering as specified in the current materials is consistent with the documentation conventions of the IEEE spec w.r.t. our implementation. First, the IEEE spec makes no statement as to whether a particular argument is first or last on the stack; the IEEE spec merely states which arguments go into which slot in the argument array. The IEEE convention is that the first argument listed goes into the lowest argument address in the array. Our OBP implementation puts the first argument in the array last onto the stack (that is, at stack top). I checked this against the implementation of getprop: cif: getprop ( len,buf cstr phandle -- size ) The IEEE spec (and the Solaris promif code) both show the phandle argument as being the first argument. At any rate, I'm willing to update the CIF spec to clarify this question, if you want to suggest an alternative format that the spec should use. Thanks! -- Richard Barnette | Belinda giggled till she shook the house, Sun Microsystems | And Blink said Weeck! which is giggling for a mouse, Supernova Software | Ink and Mustard rudely asked his age, NWK20 3168 / UNWK20-310 | When Custard cried for a nice safe cage. (510) 936-3986 / x13986 | - Ogden Nash, "The Tale of Custard the Dragon" From sacadmin Mon Feb 13 18:26:24 2006 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 k1E2QNIQ019566 for ; Mon, 13 Feb 2006 18:26:23 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1E2QM316472; Mon, 13 Feb 2006 18:26:22 -0800 (PST) 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 <0IUN0000RO3YWC00@brm-avmta-1.central.sun.com>; Mon, 13 Feb 2006 19:26:22 -0700 (MST) Received: from nwkes-gis-mail-2.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUN000X4O3W5U40@brm-avmta-1.central.sun.com>; Mon, 13 Feb 2006 19:26:20 -0700 (MST) Received: from d1-sfbay-01.sun.com ([192.18.39.111]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id k1E2QJVs008707; Mon, 13 Feb 2006 18:26:19 -0800 (PST) Received: from conversion-daemon.d1-sfbay-01.sun.com by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IUN00901HPJ3K00@d1-sfbay-01.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Mon, 13 Feb 2006 18:26:19 -0800 (PST) Received: from [129.153.85.39] by d1-sfbay-01.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IUN00AN4O3VN700@d1-sfbay-01.sun.com>; Mon, 13 Feb 2006 18:26:19 -0800 (PST) Date: Mon, 13 Feb 2006 18:26:19 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2006/052 sun4v version API update [fast-track] In-reply-to: <4fe6ccfb94091ee2e58161675f35626c@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Richard Barnette Cc: pq-arch@Sun.COM, Firmware Arch Message-id: <43F13FCB.6050608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 References: <43DAFCFE.9080506@sun.com> <43E26217.90504@sun.com> <43ECBD53.9070104@sun.com> <6f7603372913b58f01d0ff62e087cfa4@sun.com> <4fe6ccfb94091ee2e58161675f35626c@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 3254 Richard Barnette wrote On 02/13/06 17:45,: > On Feb 13, 2006, at 8:43 AM, Richard Barnette wrote: > [ ... ] > >>> 2. For the CIF document it is not clear the ordering of the >>> output arguments. Since CIFs follow FORTH style the last >>> argument is generally the top of stack. With this in mind >>> what we have in the spec seems incorrect since the "status" >>> is the generally on the top of stack. I suggest following >>> changes to be consistent with FORTH style. >>> >> OK. Seems I've misunderstood argument ordering conventions >> for CIF documentation. Just so there's no confusion, here's >> the standard stack notation on the API: >> SUNW,set-sun4v-version ( minor major group -- act-minor status ) >> SUNW,get-sun4v-version ( group -- minor major status ) >> >> This is the actual ordering in the implementation, and is >> characteristic of definitions created by hypercall: >> > Hitu, > > I went and reviewed the IEEE spec, and I think the ordering as > specified in the current materials is consistent with the documentation > conventions of the IEEE spec w.r.t. our implementation. > > First, the IEEE spec makes no statement as to whether a particular > argument is first or last on the stack; the IEEE spec merely states > which arguments go into which slot in the argument array. The IEEE > convention is that the first argument listed goes into the lowest > argument address in the array. > > Our OBP implementation puts the first argument in the array last > onto the stack (that is, at stack top). I checked this against > the implementation of getprop: > cif: getprop ( len,buf cstr phandle -- size ) > > The IEEE spec (and the Solaris promif code) both show the phandle > argument as being the first argument. > > At any rate, I'm willing to update the CIF spec to clarify this > question, if you want to suggest an alternative format that the > spec should use. Thanks a lot for your research. Your findings are correct but by representing them using FORTH syntax would be preferred since otherwise it is confusing to know which argument is top stack and which one is not. Please change it to as follows. My MAIN concern was with ordering of the stack arguments which was little confusing. Change, SUNW,set-sun4v-version IN: group, major, minor OUT: status, act-minor to, SUNW,set-sun4v-version ( minor major group -- act-minor status ) and also change, SUNW,get-sun4v-version IN: group OUT: status, major, minor to, SUNW,get-sun4v-version ( group -- minor major status ) Note that, these changes should not delay the review process. I do, however, like to know the answer to the first question I raised in my mail. I have cut/paste it below. 1. Section 9.1.1, why are arg1 and arg2 not consistently labeled? Why is major_number not called req_major_number? or may be why not req_minor_number be called minor_number? -- 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 Mon Feb 13 18:33:20 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1E2XKIQ019607 for ; Mon, 13 Feb 2006 18:33:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1E2X5U16748; Mon, 13 Feb 2006 18:33:05 -0800 (PST) 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 <0IUN00N0BOF41I00@nwk-avmta-2.sfbay.sun.com>; Mon, 13 Feb 2006 18:33:04 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUN00AFEOF39DE0@nwk-avmta-2.sfbay.sun.com>; Mon, 13 Feb 2006 18:33:03 -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 k1E2X3Te029281; Mon, 13 Feb 2006 18:33:03 -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 k1E2WlJi020261; Mon, 13 Feb 2006 18:32:47 -0800 (PST) Date: Mon, 13 Feb 2006 18:32:47 -0800 From: David Kahn Subject: Re: FWARC/2006/052 sun4v version API update [fast-track] To: Richard Barnette Cc: pq-arch@sun.com, Firmware Arch Message-id: <43F1414F.3010001@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 User-Agent: Thunderbird 1.5 (Windows/20051201) Status: RO Content-Length: 2446 Richard Barnette wrote: > I went and reviewed the IEEE spec, and I think the ordering as > specified in the current materials is consistent with the documentation > conventions of the IEEE spec w.r.t. our implementation. You're not looking in the right place. The OFWG formally defined the client interface as a package with formally defined bindings to the client interface in proposal #215, which is a recommended practice by the OFWG, which has been adopted by Sun. http://playground.sun.com/1275/practice/#client-services If you follow the link to the proposal, you might notice it was written in 1994 and accepted as an OFWG recommended practice. Sun adopted this recommended practice. Refer to the 2nd paragraph in 1.1.1: Bindings for specific instruction sets and platform architectures may include additional instruction-set-specific or platform-specific client interface services available to client programs. Those client interface services shall also be defined as methods in this package, if they exist. Since we've adopted this recommended practice, it's standard practice within Sun to use stack diagram notation when defining a client interface for consistency with everything else we've ever done. As you noted, it solves a lot of problems by just using stack notation. Note the 2nd paragraph in 1.1.2 The client interface handler pushes the arguments from the client program argument array (if any) onto the stack in the proper order (argN is pushed first; arg1 is pushed last and is the top-most stack item). And it goes on to describe the return value handling. So arg1 (using the old notation) is top of stack, in the method defined in client-services ... The common cif handling code in OBP does this automatically as described in the 2nd paragraph of 1.1.2. (The first paragraph of that section .. not shown here .. makes it a formal requirement.) Remember that when writing the code. It doesn't show Nargs, Nreturns and the status return value from the cif itself. Nargs and Nreturns are apparent from the formal definition. So, I hope this brings this discussion to a close. Use stack diagram notation for a formal client interface definition as we've been doing for 12 years. Use a similar definition as written for the methods in section 1.4.2 in #215. There was a good reason for this request in the first place. It wasn't just done on a whim to make more work for you. Thanks, -David From sacadmin Tue Feb 14 16:50:02 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1F0o2IQ008181 for ; Tue, 14 Feb 2006 16:50:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1F0o1V06519; Tue, 14 Feb 2006 16:50:01 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IUP00903EBDXM00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 14 Feb 2006 16:50:01 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IUP00E8TEBDAP58@nwk-avmta-1.sfbay.Sun.COM>; Tue, 14 Feb 2006 16:50:01 -0800 (PST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1F0o08u008610; Tue, 14 Feb 2006 17:50:00 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IUP00901DGETP00@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM); Tue, 14 Feb 2006 17:50:00 -0700 (MST) Received: from sun.com ([129.149.204.97]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IUP00A1DEBBUS00@mail-amer.sun.com>; Tue, 14 Feb 2006 17:50:00 -0700 (MST) Date: Tue, 14 Feb 2006 16:50:02 -0800 From: Tony Sumpter Subject: 2006/052 sun4v version API update [fast-track]] Sender: Tony.Sumpter@Sun.COM To: fwarc@Sun.COM Cc: pq-arch@Sun.COM, Richard Barnette Message-id: <43F27ABA.3010402@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_f5ZYzZzbOnwPFICiEMT1zQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 7556 This is a multi-part message in MIME format. --Boundary_(ID_f5ZYzZzbOnwPFICiEMT1zQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT I'm sponsoring this case as a fast-track for Ashley Saulsbury. The fast-track timeout is Feb 21, 2006. Materials have been updated from the previous fast-track notice for this case. The materials are in the case directory under 'materials': http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/ The normative text in api-26-v6-ver.pdf is in sections 9.1.1 (other than the reference to 'Appendix B' and the Programming note) and 9.1.2. The Programming note and section 9.1.1.2 are informative. Additionally, normative text for the OBP CIF is in version-cif.txt. The case updates the HV APIs for API versioning approved in FWARC/2006/499 in the following ways: Major number 0 (zero) is reserved to have a special behavior for api_set_version: the API groups is returned to the initial un-set (not enabled) state. The effect of a set version concurrent with use of the API group is defined. The addition of the EWOULDBLOCK to 9.1.1.1 to indicate that the api_set_version call could not complete without blocking. The API group number table is removed and initial group assignments and requirements for future cases are set out below. The OBP CIF definition is added. All other aspects of the APIs defined in FWARC/2005/499 remain the same. After approval of this case: 1) Future API cases must specify API group numbers and version number for each function created or changed. 2) Assignment of an API group number will not require a separate case from the APIs defined in it. 3) The group and version numbers will be entered into the API registry with the function numbers on case approval. 4) The registry format will change to accommodate the additional information and the existing registry will be updated to the new format using the API group and version number data provided in the file api-26-v6-reg.pdf in the materials directory. This document implies that some interpretation of group and function numbers may be performed (eg function numbers of the form 0x0## are core or 0x1## are platform specific): these are NOT interfaces and the choice of ranges is purely for mnemonic and decoding convenience. Attached is the existing API registry in the proposed new format. Note that no separate table of groups is proposed since a group number cannot be assigned on its own. A registry processing tool to list by group or by case is under consideration and the exact format may vary slightly later. Tony. --Boundary_(ID_f5ZYzZzbOnwPFICiEMT1zQ) Content-type: text/plain; name=trap-registry-new.txt; x-mac-creator=0; x-mac-type=0 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=trap-registry-new.txt Name Group# Trap# Func# Major# Minor# Case#s Comment FAST_TRAP N/A 0x80 -- N/A N/A 2005/116 MMU_MAP_ADDR 0x1 0x83 -- 1 0 2005/116 MMU_UNMAP_ADDR 0x1 0x84 -- 1 0 2005/116 TTRACE_ADDENTRY 0x1 0x85 -- 1 0 2005/116 CORE_TRAP N/A 0xff -- N/A N/A 2005/116 MACH_EXIT 0x1 0x80 0x00 1 0 2005/116 MACH_DESC 0x1 0x80 0x01 1 0 2005/116 MACH_SIR 0x1 0x80 0x02 1 0 2005/116 MACH_SET_SOFT_STATE 0x1 0x80 0x03 1 0 2005/419 MACH_GET_SOFT_STATE 0x1 0x80 0x04 1 0 2005/419 CPU_START 0x1 0x80 0x10 1 0 2005/116 CPU_STOP 0x1 0x80 0x11 1 0 2005/116 CPU_YIELD 0x1 0x80 0x12 1 0 2005/116 MACH_SET_WATCHDOG 0x1 0x80 0x13 1 0 2005/367 CPU_QCONF 0x1 0x80 0x14 1 0 2005/116 CPU_QINFO 0x1 0x80 0x15 1 0 2005/116 CPU_MYID 0x1 0x80 0x16 1 0 2005/116 CPU_STATE 0x1 0x80 0x17 1 0 2005/116 CPU_SET_RTBA 0x1 0x80 0x18 1 0 2005/116 CPU_GET_RTBA 0x1 0x80 0x19 1 0 2005/116 MMU_TSB_CTX0 0x1 0x80 0x20 1 0 2005/116 MMU_TSB_CTXNON0 0x1 0x80 0x21 1 0 2005/116 MMU_DEMAP_PAGE 0x1 0x80 0x22 1 0 2005/116 MMU_DEMAP_CTX 0x1 0x80 0x23 1 0 2005/116 MMU_DEMAP_ALL 0x1 0x80 0x24 1 0 2005/116 MMU_MAP_PERM_ADDR 0x1 0x80 0x25 1 0 2005/116 MMU_FAULT_AREA_CONF 0x1 0x80 0x26 1 0 2005/116 MMU_ENABLE 0x1 0x80 0x27 1 0 2005/116 MMU_UNMAP_PERM_ADDR 0x1 0x80 0x28 1 0 2005/116 MMU_TSB_CTX0_INFO 0x1 0x80 0x29 1 0 2005/116 MMU_TSB_CTXNON0_INFO 0x1 0x80 0x2a 1 0 2005/116 MMU_FAULT_AREA_INFO 0x1 0x80 0x2b 1 0 2005/116 MEM_SCRUB 0x1 0x80 0x31 1 0 2005/116 MEM_SYNC 0x1 0x80 0x32 1 0 2005/116 CPU_MONDO_SEND 0x1 0x80 0x42 1 0 2005/116 TOD_GET 0x1 0x80 0x50 1 0 2005/116 TOD_SET 0x1 0x80 0x51 1 0 2005/116 CONS_GETCHAR 0x1 0x80 0x60 1 0 2005/116 CONS_PUTCHAR 0x1 0x80 0x61 1 0 2005/116 SVC_SEND 0x102 0x80 0x80 1 0 2005/173 SVC_RCV 0x102 0x80 0x81 1 0 2005/173 SVC_GETSTATUS 0x102 0x80 0x82 1 0 2005/173 SVC_SETSTATUS 0x102 0x80 0x83 1 0 2005/173 SVC_CLRSTATUS 0x102 0x80 0x84 1 0 2005/173 TTRACE_BUF_CONF 0x1 0x80 0x90 1 0 2005/116 TTRACE_BUF_INFO 0x1 0x80 0x91 1 0 2005/116 TTRACE_ENABLE 0x1 0x80 0x92 1 0 2005/116 TTRACE_FREEZE 0x1 0x80 0x93 1 0 2005/116 DUMP_BUF_UPDATE 0x1 0x80 0x94 1 0 2005/116 DUMP_BUF_INFO 0x1 0x80 0x95 1 0 2005/116 INTR_DEVINO2SYSINO 0x1 0x80 0xa0 1 0 2005/116 INTR_GETENABLED 0x1 0x80 0xa1 1 0 2005/116 INTR_SETENABLED 0x1 0x80 0xa2 1 0 2005/116 INTR_GETSTATE 0x1 0x80 0xa3 1 0 2005/116 INTR_SETSTATE 0x1 0x80 0xa4 1 0 2005/116 INTR_GETTARGET 0x1 0x80 0xa5 1 0 2005/116 INTR_SETTARGET 0x1 0x80 0xa6 1 0 2005/116 PCI_IOMMU_MAP 0x100 0x80 0xb0 1 0 2005/112 PCI_IOMMU_DEMAP 0x100 0x80 0xb1 1 0 2005/112 PCI_IOMMU_GETMAP 0x100 0x80 0xb2 1 0 2005/112 PCI_IOMMU_GETBYPASS 0x100 0x80 0xb3 1 0 2005/112 PCI_CONFIG_GET 0x100 0x80 0xb4 1 0 2005/112 PCI_CONFIG_PUT 0x100 0x80 0xb5 1 0 2005/112 PCI_PEEK 0x100 0x80 0xb6 1 0 2005/112 PCI_POKE 0x100 0x80 0xb7 1 0 2005/112 PCI_DMA_SYNC 0x100 0x80 0xb8 1 0 2005/112 PCI_MSIQ_CONF 0x100 0x80 0xc0 1 0 2005/112 PCI_MSIQ_INFO 0x100 0x80 0xc1 1 0 2005/112 PCI_MSIQ_GETVALID 0x100 0x80 0xc2 1 0 2005/112 PCI_MSIQ_SETVALID 0x100 0x80 0xc3 1 0 2005/112 PCI_MSIQ_GETSTATE 0x100 0x80 0xc4 1 0 2005/112 PCI_MSIQ_SETSTATE 0x100 0x80 0xc5 1 0 2005/112 PCI_MSIQ_GETHEAD 0x100 0x80 0xc6 1 0 2005/112 PCI_MSIQ_SETHEAD 0x100 0x80 0xc7 1 0 2005/112 PCI_MSIQ_GETTAIL 0x100 0x80 0xc8 1 0 2005/112 PCI_MSI_GETVALID 0x100 0x80 0xc9 1 0 2005/112 PCI_MSI_SETVALID 0x100 0x80 0xca 1 0 2005/112 PCI_MSI_GETMSIQ 0x100 0x80 0xcb 1 0 2005/112 PCI_MSI_SETMSIQ 0x100 0x80 0xcc 1 0 2005/112 PCI_MSI_GETSTATE 0x100 0x80 0xcd 1 0 2005/112 PCI_MSI_SETSTATE 0x100 0x80 0xce 1 0 2005/112 PCI_MSG_GETMSIQ 0x100 0x80 0xd0 1 0 2005/112 PCI_MSG_SETMSIQ 0x100 0x80 0xd1 1 0 2005/112 PCI_MSG_GETVALID 0x100 0x80 0xd2 1 0 2005/112 PCI_MSG_SETVALID 0x100 0x80 0xd3 1 0 2005/112 LDC_TX_QCONF 0x101 0x80 0xe0 1 0 2005/739 LDC_TX_QINFO 0x101 0x80 0xe1 1 0 2005/739 LDC_TX_GET_STATE 0x101 0x80 0xe2 1 0 2005/739 LDC_TX_SET_QTAIL 0x101 0x80 0xe3 1 0 2005/739 LDC_RX_QCONF 0x101 0x80 0xe4 1 0 2005/739 LDC_RX_QINFO 0x101 0x80 0xe5 1 0 2005/739 LDC_RX_GET_STATE 0x101 0x80 0xe6 1 0 2005/739 LDC_RX_SET_QHEAD 0x101 0x80 0xe7 1 0 2005/739 NIAGARA_GET_PERFREG 0x200 0x80 0x100 1 0 2005/164 NIAGARA_SET_PERFREG 0x200 0x80 0x101 1 0 2005/164 NIAGARA_MMUSTAT_CONF 0x200 0x80 0x102 1 0 2005/467 NIAGARA_MMUSTAT_INFO 0x200 0x80 0x103 1 0 2005/467 NCS_REQUEST 0x103 0x80 0x110 1 0 2005/125 FIRE_GET_PERFREG 0x201 0x80 0x120 1 0 2006/002 FIRE_SET_PERFREG 0x201 0x80 0x121 1 0 2006/002 DIAG_RA2PA 0x300 0x80 0x200 1 0 2005/251 DIAG_HEXEC 0x300 0x80 0x201 1 0 2005/251 API_SET_VERSION N/A 0xff 0x00 N/A N/A 2005/116,499 (API_VER) API_PUTCHAR N/A 0xff 0x01 N/A N/A 2005/116 API_EXIT N/A 0xff 0x02 N/A N/A 2005/116 API_GET_VERSION N/A 0xff 0x03 N/A N/A 2005/499 --Boundary_(ID_f5ZYzZzbOnwPFICiEMT1zQ)-- From sacadmin Wed Feb 22 23:22:54 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1N7MsIQ022732 for ; Wed, 22 Feb 2006 23:22:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1N7Mr819431; Thu, 23 Feb 2006 00:22:53 -0700 (MST) 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 <0IV400601PU4TO00@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Feb 2006 23:22:52 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IV400LXUPU3HT60@nwk-avmta-2.sfbay.sun.com>; Wed, 22 Feb 2006 23:22:51 -0800 (PST) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1N7Mo8u026346; Thu, 23 Feb 2006 00:22:51 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IV400B01PSC0300@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM); Thu, 23 Feb 2006 00:22:50 -0700 (MST) Received: from sun.com ([129.150.21.4]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IV4002LDPU19910@mail-amer.sun.com>; Thu, 23 Feb 2006 00:22:50 -0700 (MST) Date: Wed, 22 Feb 2006 23:22:50 -0800 From: Tony Sumpter Subject: Re: 2006/052 sun4v version API update [fast-track]] In-reply-to: <43F27ABA.3010402@sun.com> Sender: Tony.Sumpter@Sun.COM To: fwarc@Sun.COM Cc: pq-arch@Sun.COM, Richard Barnette Message-id: <43FD62CA.2020707@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 References: <43F27ABA.3010402@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 2686 This case has timed out and hence it is now approved. Tony. Tony Sumpter wrote: > I'm sponsoring this case as a fast-track for Ashley Saulsbury. > The fast-track timeout is Feb 21, 2006. Materials have been > updated from the previous fast-track notice for this case. > > The materials are in the case directory under 'materials': > http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/ > The normative text in api-26-v6-ver.pdf is in sections 9.1.1 (other than > the reference to 'Appendix B' and the Programming > note) and 9.1.2. The Programming note and section 9.1.1.2 are > informative. > > Additionally, normative text for the OBP CIF is in version-cif.txt. > > The case updates the HV APIs for API versioning approved in > FWARC/2006/499 in the following ways: > > Major number 0 (zero) is reserved to have a special behavior > for api_set_version: the API groups is returned to the initial > un-set (not enabled) state. > > The effect of a set version concurrent with use of the > API group is defined. > > The addition of the EWOULDBLOCK to 9.1.1.1 to indicate that > the api_set_version call could not complete without blocking. > > The API group number table is removed and initial group assignments > and requirements for future cases are set out below. > > The OBP CIF definition is added. > > All other aspects of the APIs defined in FWARC/2005/499 remain the > same. > > After approval of this case: > > 1) Future API cases must specify API group numbers and version number > for each function created or changed. > > 2) Assignment of an API group number will not require a separate > case from the APIs defined in it. > > 3) The group and version numbers will be entered into the API registry > with the function numbers on case approval. > > 4) The registry format will change to accommodate the > additional information and the existing registry will be updated > to the new format using the API group and version number data > provided in the file api-26-v6-reg.pdf in the materials directory. > This document implies that some interpretation of group and function > numbers may be performed (eg function numbers of the form 0x0## are > core or 0x1## are platform specific): these are NOT interfaces and the > choice of ranges is purely for mnemonic and decoding convenience. > > Attached is the existing API registry in the proposed new format. > > Note that no separate table of groups is proposed since a group number > cannot be assigned on its own. A registry processing tool to list > by group or by case is under consideration and the exact format may > vary slightly later. > > Tony. > From sacadmin Mon Feb 27 14:35:06 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1RMZ6IQ023936 for ; Mon, 27 Feb 2006 14:35:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1RMZ6e02851 for <@sunmail3.sfbay.sun.com:fwarc-members@sun.com>; Mon, 27 Feb 2006 14:35:06 -0800 (PST) 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 <0IVD00501AQIBL00@nwk-avmta-2.sfbay.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 14:35:06 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IVD004MJAQHWQ00@nwk-avmta-2.sfbay.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 14:35:06 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1RMZ5SD012660 for ; Mon, 27 Feb 2006 15:35:05 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IVD00101A8DZX00@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM) for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 15:35:05 -0700 (MST) Received: from sun.com ([129.150.22.95]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IVD007KIAQB4K00@mail-amer.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 15:35:05 -0700 (MST) Date: Mon, 27 Feb 2006 14:35:00 -0800 From: Tony Sumpter Subject: 2006/052 typo in CIF spec: how to correct? Sender: Tony.Sumpter@Sun.COM To: Fwarc members Message-id: <44037E94.2000703@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 483 When the project team reviewed the text for the CIF interface, now at http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/materials/versions-cif.txt no one spotted the discrepency between the names the project had agreed and the names in the spec text. The project had decided on the names SUNW,set-sun4v-api-version and SUNW,get-sun4v-api-version. The versions-cif.txt file has the names without "-api" in them. What process should I follow to correct this typo? Tony. From sacadmin Mon Feb 27 16:50:27 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1S0oRIQ000371 for ; Mon, 27 Feb 2006 16:50:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1S0oRe22676 for <@sunmail2.sfbay.sun.com:fwarc-members@sun.com>; Mon, 27 Feb 2006 16:50:27 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IVD00H05H02RS00@nwk-avmta-1.sfbay.Sun.COM> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 16:50:26 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IVD00BAEH02W7EB@nwk-avmta-1.sfbay.Sun.COM> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 16:50:26 -0800 (PST) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id k1S0oPVs003390 for ; Mon, 27 Feb 2006 16:50:25 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IVD00C01GPHAK00@d1-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 16:50:25 -0800 (PST) Received: from [129.153.85.39] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IVD0071NH01CL20@d1-sfbay-10.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 16:50:25 -0800 (PST) Date: Mon, 27 Feb 2006 16:50:25 -0800 From: Hitendra Zhangada Subject: Re: 2006/052 typo in CIF spec: how to correct? In-reply-to: <44037E94.2000703@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Fwarc members Message-id: <44039E51.4020708@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 References: <44037E94.2000703@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 1363 Tony Sumpter wrote On 02/27/06 14:35,: > When the project team reviewed the text for the CIF interface, now at > http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/materials/versions-cif.txt > > no one spotted the discrepency between the names the project had agreed > and the names in the spec text. The project had decided on the names > SUNW,set-sun4v-api-version and SUNW,get-sun4v-api-version. The > versions-cif.txt > file has the names without "-api" in them. > > What process should I follow to correct this typo? For these sort of changes, we can submit a fast-track which makes the previously approved names obsolete and establishes classifications for the new interfaces. I suggest you file a fast-track for this change. Another ugly option would be to modify the IAM file and change the state of the 2006/052. I don't think we have ever done this sort of things and not sure if this is even allowed. If you are concerned about "timing" then may be we request ARC members for a shorter review period. I am fine with -api in the name and hence I will review/approve it the day you submit the case. -- 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 Mon Feb 27 21:19:35 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1S5JZIQ016825 for ; Mon, 27 Feb 2006 21:19:35 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1S5JYY15576 for <@sunmail1brm.central.sun.com:fwarc-members@sun.com>; Mon, 27 Feb 2006 22:19:34 -0700 (MST) 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 <0IVD00H01TGMAK00@brm-avmta-1.central.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 22:19:34 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IVD00AG3TGLZJ50@brm-avmta-1.central.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Mon, 27 Feb 2006 22:19:33 -0700 (MST) 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 k1S5JXTe000604; Mon, 27 Feb 2006 21:19:33 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.12.10+Sun/8.12.10) with ESMTP id k1S5JUZO041491; Mon, 27 Feb 2006 21:19:31 -0800 (PST) Date: Mon, 27 Feb 2006 21:19:26 -0800 From: David Kahn Subject: Re: 2006/052 typo in CIF spec: how to correct? To: Tony Sumpter Cc: Fwarc members Message-id: <4403DD5E.1060106@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 User-Agent: Thunderbird 1.5 (Windows/20051201) Status: RO Content-Length: 1538 > Tony Sumpter wrote On 02/27/06 14:35,: >> When the project team reviewed the text for the CIF interface, now at >> http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/materials/versions-cif.txt >> >> no one spotted the discrepency between the names the project had agreed >> and the names in the spec text. The project had decided on the names >> SUNW,set-sun4v-api-version and SUNW,get-sun4v-api-version. The >> versions-cif.txt >> file has the names without "-api" in them. Are you sure? The OBP cif name space is separate from the HV API name space. They don't have to match character for character. (Though, admittedly, I'm usually the one arguing for consistency.) > For these sort of changes, we can submit a fast-track which makes > the previously approved names obsolete and establishes classifications > for the new interfaces. You can do a fast-track. I think this level if change qualifies for self-review so if you do this, please submit it as a self-review case. Use the fast-track script, include review type: self-review in the one-pager, then change the IAM file ... per status.allowed: closed approved automatic( MM/DD/YYYY)? # Sometimes a project that qualifies for self review will # present itself to the ARCs for informational reasons - maybe # it needs a case number to satisfy some SC/PAC tracking needs. # This value indicates that the project does not require any # explicit ARC approval or actions. -David From sacadmin Tue Feb 28 10:29:36 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1SITaIQ007818 for ; Tue, 28 Feb 2006 10:29:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1SITZF10666 for <@sunmail2.sfbay.sun.com:fwarc-members@sun.com>; Tue, 28 Feb 2006 11:29:35 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IVE00F07U19D700@nwk-avmta-1.sfbay.Sun.COM> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Tue, 28 Feb 2006 10:29:33 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IVE00BW6U16W1NC@nwk-avmta-1.sfbay.Sun.COM> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Tue, 28 Feb 2006 10:29:30 -0800 (PST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1SITTSH016661 for ; Tue, 28 Feb 2006 11:29:30 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IVE00201TWE4E00@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM) for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Tue, 28 Feb 2006 11:29:29 -0700 (MST) Received: from sun.com ([129.150.23.176]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IVE00LTAU0Z0550@mail-amer.sun.com> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Tue, 28 Feb 2006 11:29:24 -0700 (MST) Date: Tue, 28 Feb 2006 10:29:23 -0800 From: Tony Sumpter Subject: Re: 2006/052 typo in CIF spec: how to correct? In-reply-to: <4403DD5E.1060106@sun.com> Sender: Tony.Sumpter@Sun.COM To: Fwarc members Message-id: <44049683.7020003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 References: <4403DD5E.1060106@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 1698 Self review case 2006/137 has been created for this. Tony. David Kahn wrote: > > >> Tony Sumpter wrote On 02/27/06 14:35,: >> >>> When the project team reviewed the text for the CIF interface, now at >>> http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/materials/versions-cif.txt >>> >>> no one spotted the discrepency between the names the project had agreed >>> and the names in the spec text. The project had decided on the names >>> SUNW,set-sun4v-api-version and SUNW,get-sun4v-api-version. The >>> versions-cif.txt >>> file has the names without "-api" in them. > > > Are you sure? The OBP cif name space is separate from the > HV API name space. They don't have to match character for character. > (Though, admittedly, I'm usually the one arguing for consistency.) > >> For these sort of changes, we can submit a fast-track which makes >> the previously approved names obsolete and establishes classifications >> for the new interfaces. > > > You can do a fast-track. I think this level if change qualifies for > self-review > so if you do this, please submit it as a self-review case. Use the > fast-track > script, include review type: self-review in the one-pager, then change > the IAM > file ... per status.allowed: > > closed approved automatic( MM/DD/YYYY)? > # Sometimes a project that qualifies for self review will > # present itself to the ARCs for informational reasons - > maybe > # it needs a case number to satisfy some SC/PAC tracking > needs. > # This value indicates that the project does not require > any > # explicit ARC approval or actions. > > -David > From sacadmin Tue Feb 28 10:34:16 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1SIYFIQ007973 for ; Tue, 28 Feb 2006 10:34:16 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k1SIXRi2014694 for <@sunmail2.sfbay.sun.com:fwarc-members@sun.com>; Wed, 1 Mar 2006 02:34:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IVE00F01U8ZSR00@nwk-avmta-1.sfbay.Sun.COM> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Tue, 28 Feb 2006 10:34:11 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IVE00B0OU8ZWBQC@nwk-avmta-1.sfbay.Sun.COM> for fwarc-members@sun.com (ORCPT fwarc-members@sun.com); Tue, 28 Feb 2006 10:34:11 -0800 (PST) Received: from phys-hanwk-1 (phys-hanwk-1.SFBay.Sun.COM [129.149.2.111]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1SIYBLn015628 for ; Tue, 28 Feb 2006 10:34:11 -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 <0IVE00B01U3GHX@hanwk-mail1.sfbay.sun.com> (original mail from richard.barnette@sun.com) for fwarc-members@sun.com; Tue, 28 Feb 2006 10:34:11 -0800 (PST) Received: from [192.168.1.102] (vpn-129-150-25-161.SFBay.Sun.COM [129.150.25.161]) by hanwk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IVE00AHWU8QXT@hanwk-mail1.sfbay.sun.com> for fwarc-members@sun.com; Tue, 28 Feb 2006 10:34:03 -0800 (PST) Date: Tue, 28 Feb 2006 10:34:13 -0800 From: Richard Barnette Subject: Re: 2006/052 typo in CIF spec: how to correct? In-reply-to: <4403DD5E.1060106@sun.com> To: Fwarc members Message-id: <01fe23bd9976bf7cf058b2c23a6f8c84@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 References: <4403DD5E.1060106@sun.com> Status: RO Content-Length: 1822 On Feb 27, 2006, at 9:19 PM, David Kahn wrote: >> Tony Sumpter wrote On 02/27/06 14:35,: >>> When the project team reviewed the text for the CIF interface, now at >>> http://sac.sfbay.sun.com/Archives/CaseLog/arc/FWARC/2006/052/ >>> materials/versions-cif.txt >>> no one spotted the discrepency between the names the project had >>> agreed >>> and the names in the spec text. The project had decided on the names >>> SUNW,set-sun4v-api-version and SUNW,get-sun4v-api-version. The >>> versions-cif.txt >>> file has the names without "-api" in them. > > Are you sure? The OBP cif name space is separate from the > HV API name space. They don't have to match character for character. > (Though, admittedly, I'm usually the one arguing for consistency.) > The suggested change isn't for consistency with the HV names; its for consistency between the actual code and the CIF specification, both in Solaris promif, and in OBP. >> For these sort of changes, we can submit a fast-track which makes >> the previously approved names obsolete and establishes classifications >> for the new interfaces. > > You can do a fast-track. I think this level if change qualifies for > self-review > so if you do this, please submit it as a self-review case. Use the > fast-track > script, include review type: self-review in the one-pager, then change > the IAM > file ... per status.allowed: > This sounds like just the process for this problem. Thanks! > -David > -- Richard Barnette | Belinda giggled till she shook the house, Sun Microsystems | And Blink said Weeck! which is giggling for a mouse, Supernova Software | Ink and Mustard rudely asked his age, NWK20 3168 / UNWK20-310 | When Custard cried for a nice safe cage. (510) 936-3986 / x13986 | - Ogden Nash, "The Tale of Custard the Dragon" From sacadmin Tue Mar 14 16:23:19 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2F0NJIQ007350 for ; Tue, 14 Mar 2006 16:23:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k2F0NJm00650 for <@sunmail1brm.central.sun.com:fwarc@sun.com>; Tue, 14 Mar 2006 17:23:19 -0700 (MST) 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 <0IW500J0B7QTW100@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 14 Mar 2006 17:23:17 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IW500FWD7QTND50@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 14 Mar 2006 17:23:17 -0700 (MST) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k2F0NH8u001491 for ; Tue, 14 Mar 2006 17:23:17 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IW500L016ZSPU00@mail-amer.sun.com> (original mail from Tony.Sumpter@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 14 Mar 2006 17:23:17 -0700 (MST) Received: from sun.com ([129.149.204.97]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IW50095S7QS8T70@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 14 Mar 2006 17:23:17 -0700 (MST) Date: Tue, 14 Mar 2006 16:23:16 -0800 From: Tony Sumpter Subject: Hypervisor API Registry update (2006/052) Sender: Tony.Sumpter@Sun.COM To: Firmware Arch Message-id: <44175E74.50409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 Status: RO Content-Length: 190 I have updated the format of the Hypervisor API Registry as approved in case 2006/052. Here is the URL for reference: http://sac.eng.sun.com/arc/FWARC/Registries/trap-registry.txt Tony.