From sacadmin Thu Feb 21 15:02:21 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LN2Lwn005118 for ; Thu, 21 Feb 2008 15:02:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1LN2JQX025683; Thu, 21 Feb 2008 15:02:21 -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 <0JWM002232NTHQ00@brm-avmta-1.central.sun.com>; Thu, 21 Feb 2008 16:02: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 <0JWM00KXH2NRUP40@brm-avmta-1.central.sun.com>; Thu, 21 Feb 2008 16:02:15 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1LN2FXL025845; Thu, 21 Feb 2008 23:02:15 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00K012IHWT00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) ; Thu, 21 Feb 2008 16:02:15 -0700 (MST) Received: from [129.150.20.100] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM000ZT2NPBF80@mail-amer.sun.com>; Thu, 21 Feb 2008 16:02:14 -0700 (MST) Date: Thu, 21 Feb 2008 15:02:12 -0800 From: Sunit Jain Subject: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer Sender: S.Jain@sun.com To: Firmware Arch Cc: Raghunath.Shenbagam@sun.com, Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: S.Jain@sun.com Message-id: <47BE02F4.2010100@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_/bwt71/VSA++8yk80FoH+A)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.12pre (Windows/20080123) Status: RO Content-Length: 8473 This is a multi-part message in MIME format. --Boundary_(ID_/bwt71/VSA++8yk80FoH+A) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I am sponsoring this fast track for Raghunath Shenbagam. This case modifies the existing HV Watchdog API (MACH_SET_WATCHDOG) to support Hardware (ATCA) Watchdog patting function. Updated WDT API specification, interface table and the one-pager have been copied to case materials directory - One pager: http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/1-pager.txt HV WDT API spec: http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/api-wdog.pdf I/F table: http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/interface-table.txt Case timer is set to expire on Friday, Feb. 28th 2008. Release Binding: firmware: minor/micro firmware release OS: minor/micro/patch OS release. --Boundary_(ID_/bwt71/VSA++8yk80FoH+A) Content-type: text/plain; name=1-pager.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=1-pager.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Hypervisor support for Hardware Watchdog Timer 1.2. Name of Document Author/Supplier: Raghunath Shenbagam (Raghunath.Shenbagam@sun.com) Jack Bochsler (Jack.Bochsler@sun.com) 1.3. Date of This Document: 15 February 2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: NSN PAC 1.4.2. The ARC(s) you expect to review your project: FWARC 1.4.3. The Director/VP who is "Sponsoring" this project: Jesse Lawrendra (Jesse.Lawrendra@sun.com) 1.4.4. The name of your business unit: Netra Systems and Networking Group 1.5. Email Aliases: 1.5.1. Responsible Manager: Mehrdad Mojgoani (Mehrdad.Mojgani@sun.com) 1.5.2. Responsible Engineer: Raghunath Shenbagam (Raghunath.Shenbagam@sun.com) 1.5.3. Marketing Manager: Pocheng.Shyu@sun.com 1.5.4. Interest List: atca-wdt-dev@sun.com 2. Project Summary 2.1. Project Description: On ATCA CMT blade platforms, system management software monitors health of the applications running on the host. To detect application hang, an external hardware watchdog is provided by an Intelligent Platform Management Controller (IPMC). Hypervisor needs to provide support to access the IPMC WatchDog function from the host application. This project enable a host application to transparently access FPGA register using Hypervisor API. 2.2. Risks and Assumptions: The Hypervisor watchdog timer api is used to access both hypervisor watchdog (hv wdt) and hardware watchdog (hw wdt or atca wdt). There are no checks to prevent two client, one patting hw wdt and another patting hv wdt. The assumption is that the user is aware of both wdt and uses them accordingly. 3. Business Summary 3.1. Problem Area: Hypervisor should provide support to access Hardware Watchdog timer (in IPMC). 3.2. Market/Requester: N/A 3.3. Business Justification: Hardware Watchdog (ATCA WD) is a requirement from XXXXXX and XXXXXX. 3.4. Competitive Analysis: N/A 3.5. Opportunity Window/Exposure: N/A 3.6. How will you know when you are done?: Detect an application failure in 100ms using IPMC Watchdog timer. 4. Technical Description: 4.1. Details: This proposal is a modification of FWARC/2006/199 to enable support for platform specific hardware watchdog timers. Although the initial support is desired for the "Monza" platform, the intent is to make the support generic to support future additional platforms. The hardware watchdog timer functionality is provided in the Intelligent Platform Management Controller (IPMC). IPMC watchdog is a hardware watchdog implementation in IPMC and conforms to IPMI specification. It can be used to monitor the health of telco applications (running on the host). The hardware watchdog timer enable (setup) and disable are performed by sending IPMI messages to iLOM over ldc channel. iLOM then forwards it to IPMC over serial line (more details in document listed in 5.b) A simple, light weight control path is defined between the management software and hardware watchdog function in IPMC. IPMC provides an IPMI_WD signal that can be used to interrupt the IPMC to "pat" the watchdog. The IPMI_WD interrupt is triggered by accessing the FPGA register for WDT. To facilitate FPGA access, the pre-existing Hypervisor watchdog interface needs to be augmented to write to the implementation specific FPGA address in order to 'pat' the watchdog when called by the host. Application -> Kernel IPMC WD Mod. -> Hypervisor -> FPGA -> IPMC WDT This project enable the interface between Solaris kernel to pat IPMC WDT by providing access to FPGA register. To enable FPGA access, two new Machine Description (MD) properties are defined to indicate the WDT control register offset and an enable bit. hw_wd_address - Platform MD property that defines register offset. hw_wd_pat_value - Platform MD property that defines register write value to enable/pat the watchdog timer. IPMC watchdog provides a system level watchdog functionality. Any IPMC wdt expiry results in a system level action. IPMC watchdog can not be used to monitor applications running on multiple guest OS's. A two level WDT monitoring approach is used in this case: Per domain HV WDT implementation is used to monitor the health of application in each guest domain, while IPMC WDT is used to monitor the control domain. The proposed modification to the HV Watchdog interface is backwards compatible and will not require any modifications to guests that leverage only the HV WDT. It is possible for a guest domain to use both HW WDT and the HV WDT concurrently, although this is not the expected configuration. No new interfaces are being introduced. The existing interface is being extended to support the HW WDT in a backwards compatible way. The current implementation is as follows: If the argument to hcall_set_watchdog (timeout) is zero, HV WDT is disabled, otherwise pat the watchdog: timeout: hv_wd 0 disable !0 pat This is being extended to as in the following table, with the additional discriminator of whether the hw_wd_address property is defined. The first two lines below (where hw_wd_address is either not defined, or defined as zero) result in the identical behavior as above. The last two lines represent the newly added behavior. timeout hw_wd_address hv_wd hw_wd 0 0 disable nop !0 0 pat nop 0 !0 disable pat !0 !0 pat nop 4.2. Bug/RFE Number(s): CR6650354 Need hardware Watchdog timer patting support of 100ms per IPMI specification 4.3. In Scope: This 1-pager describe changes in Hypervisor to support ATCA WDT. 4.4. Out of Scope: Changes to other components (FPGA/IPMC/Solaris) is not covered by this 1-pager. 4.5. Interfaces: There is no change to pre-existing interface stability level. This interface remains Sun Private. Please see interface-table.txt 5. Reference Documents: a. Requirement Specification for Watchdog Timer support http://vsp72-128.sfbay/twiki/pub/TRC/WebHome/WDT-RS-0.3.odt b. 1-pager/Doc. to NSARC http://vsp72-128.sfbay/twiki/bin/view/ATCA/AtcaRThreeUpdate1 - OnePager for CMT ATCA WDT: Ver 2.0 - ATCA WDT write-up: Ver 2.0 c. HV Watchdog Interface Spec: http://sw.west/~jackb/atca/interface-table.txt d. Hypervisor API updated pages: http://sw.west/~jackb/atca/api-wdog.pdf e. Prior and related FWARC cases: FWARC/2005/115 sun4v machine description FWARC/2005/116 sun4v core API FWARC/2005/367 sun4v watchdog service API FWARC/2006/093 sun4v watchdog API update FWARC/2006/199 sun4v watchdog API fn correction 6. Resources and Schedule: 6.1. Projected Availability: March '08 6.2. Cost of Effort: 1 Week for development. 1 Week for Integration. 1 Week for FWARC documents. 6.5. ARC review type: FastTrack 7. Prototype Availability: 7.1. Prototype Availability: Prototype available. --Boundary_(ID_/bwt71/VSA++8yk80FoH+A)-- From sacadmin Thu Feb 21 15:26:12 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNQCAV005555 for ; Thu, 21 Feb 2008 15:26:12 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1LNQ9ZR002945; Thu, 21 Feb 2008 15:26:11 -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 <0JWM004073RMD000@brm-avmta-1.central.sun.com>; Thu, 21 Feb 2008 16:26:10 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00KRL3RKUV70@brm-avmta-1.central.sun.com>; Thu, 21 Feb 2008 16:26:09 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1LNQ8SE006484; Thu, 21 Feb 2008 15:26:08 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNQ7Zq071486; Thu, 21 Feb 2008 15:26:07 -0800 (PST) Date: Thu, 21 Feb 2008 15:26:06 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer To: Sunit Jain Cc: Firmware Arch , Raghunath.Shenbagam@sun.com, Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE088E.9090101@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 210 How does the guest know if the hw wd exists or not? Are there MD nodes for it? Where are they described? If there's an MD node, is that where the address comes from? (the one used in the API calls.) -David From sacadmin Thu Feb 21 15:28:03 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNS2NO005568 for ; Thu, 21 Feb 2008 15:28:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1LNS1nn028974; Fri, 22 Feb 2008 07:28:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWM004013UOQQ00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 15:28:00 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM004T83UO8I10@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 15:28:00 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1LNRxcn007580; Thu, 21 Feb 2008 15:27:59 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNRwna071593; Thu, 21 Feb 2008 15:27:58 -0800 (PST) Date: Thu, 21 Feb 2008 15:27:57 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer To: Sunit Jain Cc: Firmware Arch , Raghunath.Shenbagam@sun.com, Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE08FD.6010107@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 299 Also, I was wondering if the project team considered a separate API (and separate LDC) for the hw watch dog? That way the API could return ENOTSUPPORTED or something like that on platforms that don't have it. What happens today if it doesn't exist, and they use the new form of the API? -David From sacadmin Thu Feb 21 15:38:29 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNcTS5005603 for ; Thu, 21 Feb 2008 15:38:29 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1LNcRnv011083; Thu, 21 Feb 2008 16:38:28 -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-3.04 (built Jul 15 2005)) id <0JWM006054C3IO00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 15:38:27 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00B3L4C2OTA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 15:38:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1LNcQSk027746; Thu, 21 Feb 2008 15:38:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00D014BPVW00@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 15:38:26 -0800 (PST) Received: from [192.168.0.3] ([71.141.160.49]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM007YS4BV4T20@fe-sfbay-09.sun.com>; Thu, 21 Feb 2008 15:38:20 -0800 (PST) Date: Thu, 21 Feb 2008 15:38:27 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE088E.9090101@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE0B73.5010501@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 502 David Kahn wrote: > How does the guest know if the hw wd exists or not? The hardware watchdog is managed only by application running in the control domain. The IPMI calls to setup watchdog would fail is there is no hw wdt(atca wdt). > > Are there MD nodes for it? Where are they described? > If there's an MD node, is that where the address comes > from? (the one used in the API calls.) There is no separate node for hw wdt. The new MD properties are defined in the platforms node. Regards, Raghu From sacadmin Thu Feb 21 15:45:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNj6mW005638 for ; Thu, 21 Feb 2008 15:45:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1LNj24R012292; Thu, 21 Feb 2008 16:45:05 -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 <0JWM0050X4N5JP00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 15:45:05 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM004AM4N58E30@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 15:45:05 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1LNj5Mo028567; Thu, 21 Feb 2008 15:45:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM006014H96000@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 15:45:05 -0800 (PST) Received: from [192.168.0.3] ([71.141.160.49]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM00LCU4N2ZFE0@fe-sfbay-10.sun.com>; Thu, 21 Feb 2008 15:45:03 -0800 (PST) Date: Thu, 21 Feb 2008 15:45:10 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE08FD.6010107@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE0D06.9040603@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE08FD.6010107@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 675 David Kahn wrote: > > Also, I was wondering if the project team > considered a separate API (and separate LDC) > for the hw watch dog? We've discussed having a separate API with HV team. HV team feel overloading hv wdt i/f is the better approach. > > That way the API could return ENOTSUPPORTED > or something like that on platforms that > don't have it. > > What happens today if it doesn't exist, > and they use the new form of the API? The hv api itself has not changed. The implementation of the api looks for the new MD properties, if defined, uses it to "pat" hw wdt(rather program an fpga register). Otherwise, it works like how its implemented today. Regards, Raghu From sacadmin Thu Feb 21 15:49:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LNnsFJ005654 for ; Thu, 21 Feb 2008 15:49:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1LNnlpJ006898; Thu, 21 Feb 2008 23:49:54 GMT 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 <0JWM005014V5Q800@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 15:49:53 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM004J04V48I30@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 15:49:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1LNnqdj029053; Thu, 21 Feb 2008 15:49:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM004014TIKI00@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 15:49:52 -0800 (PST) Received: from [192.168.0.3] ([71.141.160.49]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM007EU4US4T80@fe-sfbay-09.sun.com>; Thu, 21 Feb 2008 15:49:41 -0800 (PST) Date: Thu, 21 Feb 2008 15:49:46 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE0B73.5010501@sun.com> Sender: Raghunath.Shenbagam@sun.com To: Raghunath.Shenbagam@sun.com Cc: David Kahn , Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE0E1A.6060403@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 661 Raghunath Shenbagam wrote: > David Kahn wrote: >> How does the guest know if the hw wd exists or not? > The hardware watchdog is managed only by application running in the > control domain. > The IPMI calls to setup watchdog would fail is there is no hw wdt(atca > wdt). should read: IPMI message(command) to setup watchdog would fail if there is no hw wdt(atca wdt) /Raghu >> >> Are there MD nodes for it? Where are they described? >> If there's an MD node, is that where the address comes >> from? (the one used in the API calls.) > There is no separate node for hw wdt. The new MD properties are > defined in the platforms node. > > Regards, > Raghu > From sacadmin Thu Feb 21 16:04:24 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M04OhD006125 for ; Thu, 21 Feb 2008 16:04:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1M04OUP011847; Thu, 21 Feb 2008 16:04:24 -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-3.04 (built Jul 15 2005)) id <0JWM0090F5JB3F00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 16:04:23 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00BSC5JAOUB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 16:04:22 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M04L8Y032931; Thu, 21 Feb 2008 16:04:21 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M04KHl073096; Thu, 21 Feb 2008 16:04:21 -0800 (PST) Date: Thu, 21 Feb 2008 16:04:20 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE0B73.5010501@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE1184.10008@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 592 Raghunath Shenbagam wrote: > David Kahn wrote: >> How does the guest know if the hw wd exists or not? > The hardware watchdog is managed only by application running in the > control domain. > The IPMI calls to setup watchdog would fail is there is no hw wdt(atca > wdt). ok, so the potentially generic sun4v os and apps in the control domain could look for something in the MD to tell if it should use the hw wd or not? What happens if it isn't used? (say, by a generic sun4v install, without the drivers/code needed for the hw wd?) I think this is all good. Just making sure. -David From sacadmin Thu Feb 21 17:36:22 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M1aMpD009612 for ; Thu, 21 Feb 2008 17:36:22 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1M1aLXF017533; Thu, 21 Feb 2008 17:36:22 -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-3.04 (built Jul 15 2005)) id <0JWM00J099SL6R00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 17:36:21 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00BTT9SKOQE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 17:36:20 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1M1aKBw009014; Thu, 21 Feb 2008 17:36:20 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00F019PXXO00@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 17:36:20 -0800 (PST) Received: from [192.168.0.3] ([71.141.160.49]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM00DMJ9SJEL10@fe-sfbay-09.sun.com>; Thu, 21 Feb 2008 17:36:20 -0800 (PST) Date: Thu, 21 Feb 2008 17:36:27 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE1184.10008@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE271B.1090303@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 963 David Kahn wrote: > Raghunath Shenbagam wrote: >> David Kahn wrote: >>> How does the guest know if the hw wd exists or not? >> The hardware watchdog is managed only by application running in the >> control domain. >> The IPMI calls to setup watchdog would fail is there is no hw >> wdt(atca wdt). > > ok, so the potentially generic sun4v os and apps in the control > domain could look for something in the MD to tell if it should > use the hw wd or not? The application, in this case, is a system management software that "pats" hw wdt to indicate health. The sys. mgt s/w and Solaris are oblivious of MD properties. The new MD properties are used internally by HV to determine if it should "pat" hw wdt or hv wdt. > > What happens if it isn't used? (say, by a generic sun4v install, > without the drivers/code needed for the hw wd?) Not sure i understand the Qn.. Can you elaborate? Thanks, Raghu > > > I think this is all good. Just making sure. > > -David From sacadmin Thu Feb 21 18:06:40 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M26dcA010441 for ; Thu, 21 Feb 2008 18:06:40 -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 m1M26PTj028115; Fri, 22 Feb 2008 10:06:39 +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 <0JWM00H01B701J00@brm-avmta-1.central.sun.com>; Thu, 21 Feb 2008 19:06:36 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00CSWB6ZN850@brm-avmta-1.central.sun.com>; Thu, 21 Feb 2008 19:06:36 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M26Z55040383; Thu, 21 Feb 2008 18:06:35 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M26YCx077604; Thu, 21 Feb 2008 18:06:34 -0800 (PST) Date: Thu, 21 Feb 2008 18:06:34 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE271B.1090303@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE2E2A.8050205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1242 Raghunath Shenbagam wrote: >> What happens if it isn't used? (say, by a generic sun4v install, >> without the drivers/code needed for the hw wd?) > Not sure i understand the Qn.. Can you elaborate? The idea behind sun4v, is that any platform can boot to at least the point that additional platform-specific drivers and software can be added to that platform, so each platform doesn't require a complete spin of the WOS. Any generic OS supported on that platform can be installed on that platform. You won't necessarily get the best performance using the generic sun4v OS, but it should work, at least to the point of allowing an install of platform specific packages and drivers to get the rest of the performance and features needed for that platform. What happens if nobody pats the hw wd? I imagine that somebody has to turn it on first, right? And then, once its enabled, if you don't pat it within the right timeframe, only then will the hw wd event occur, right? That's the way most of these things work. So, if it isn't enabled by this platform specific management application (which doesn't really seem to have to be platform specific with the modified API), then the hw wd won't get triggered if nobody pats it, right? -David From sacadmin Thu Feb 21 18:12:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2Ccri011296 for ; Thu, 21 Feb 2008 18:12:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1M2CY6h000804; Fri, 22 Feb 2008 10:12:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWM00B01BH0WH00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:12:36 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00B0EBGZNI20@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:12:35 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M2CZ6G042987; Thu, 21 Feb 2008 18:12:35 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2CYKq077789; Thu, 21 Feb 2008 18:12:34 -0800 (PST) Date: Thu, 21 Feb 2008 18:12:34 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE271B.1090303@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE2F92.6030300@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 679 Raghunath Shenbagam wrote: >> ok, so the potentially generic sun4v os and apps in the control >> domain could look for something in the MD to tell if it should >> use the hw wd or not? > The application, in this case, is a system management software that "pats" > hw wdt to indicate health. The sys. mgt s/w and Solaris are oblivious of > MD properties. The new MD properties are used internally by HV to > determine if it should "pat" hw wdt or hv wdt. That's confusing. The HV itself doesn't do any patting unless it's told to by the guest. (via the API). It also looks like the guest can't use the HV_WD if the hw wd timer address property in the MD is non-zero. -David From sacadmin Thu Feb 21 18:23:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2NkrG011522 for ; Thu, 21 Feb 2008 18:23:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M2Ng0L004210; Fri, 22 Feb 2008 02:23:45 GMT 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 <0JWM00C09BZKD400@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:23:44 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00B9HBZJNI60@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:23:43 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1M2Nh1r011742; Thu, 21 Feb 2008 18:23:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00701BT27300@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 18:23:43 -0800 (PST) Received: from [192.168.0.3] ([71.141.98.116]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM00LLLBZI2650@fe-sfbay-10.sun.com>; Thu, 21 Feb 2008 18:23:43 -0800 (PST) Date: Thu, 21 Feb 2008 18:23:50 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE2E2A.8050205@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE3236.8060600@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2E2A.8050205@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1379 David Kahn wrote: > Raghunath Shenbagam wrote: >>> What happens if it isn't used? (say, by a generic sun4v install, >>> without the drivers/code needed for the hw wd?) >> Not sure i understand the Qn.. Can you elaborate? > The idea behind sun4v, is that any platform can boot > to at least the point that additional platform-specific > drivers and software can be added to that platform, > so each platform doesn't require a complete spin of > the WOS. > > Any generic OS supported on that platform can be > installed on that platform. You won't necessarily > get the best performance using the generic sun4v OS, > but it should work, at least to the point of allowing > an install of platform specific packages and drivers > to get the rest of the performance and features needed > for that platform. Thanks for the details. > > What happens if nobody pats the hw wd? I imagine that > somebody has to turn it on first, right? And then, That's correct. > once its enabled, if you don't pat it within the > right timeframe, only then will the hw wd event > occur, right? That's the way most of these things Yes. > work. So, if it isn't enabled by this platform > specific management application (which doesn't really > seem to have to be platform specific with the modified > API), then the hw wd won't get triggered if nobody pats > it, right? Correct. Thx, Raghu > > > -David From sacadmin Thu Feb 21 18:23:48 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2NlKW011523 for ; Thu, 21 Feb 2008 18:23:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M2Ng0P004210; Fri, 22 Feb 2008 02:23:46 GMT 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 <0JWM00C01BZLD500@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:23:45 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00B9TBZKNI60@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:23:44 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M2NhxW049261; Thu, 21 Feb 2008 18:23:43 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2Ngqp078245; Thu, 21 Feb 2008 18:23:42 -0800 (PST) Date: Thu, 21 Feb 2008 18:23:42 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE271B.1090303@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE322E.1020208@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 765 Raghu, The more I think about this, the less I like overloading the current hv wd API. It should be relatively simple to define a new API for the hw wd that can coexist with the hv wd. That API can be in a new API group, and negotiation for it could fail on existing systems, and succeed on new systems if the hw wd is present. Or it could succeed if the API exists, and return ENOTSUPPORTED or some other error code if the hw wd doesn't exist. If the goal is to make this a generic feature supported by sun4v, that's the right way to do it. (and I think that's what the goal should be.) I'm also confused about the bit mask in the document. Is it a mask or a value? Is the address a physical address? I guess it would have to be a physical address. -David From sacadmin Thu Feb 21 18:38:12 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2cBiv011590 for ; Thu, 21 Feb 2008 18:38:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M2c8V2010381; Fri, 22 Feb 2008 02:38:11 GMT 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 <0JWM00C1NCNLW800@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:38:09 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00BCHCNKNIF0@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:38:08 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1M2c8r3012437; Thu, 21 Feb 2008 18:38:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00L01CJOL100@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 18:38:08 -0800 (PST) Received: from [192.168.0.3] ([71.141.98.116]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM00L69CNF26D0@fe-sfbay-10.sun.com>; Thu, 21 Feb 2008 18:38:03 -0800 (PST) Date: Thu, 21 Feb 2008 18:38:11 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE2F92.6030300@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE3593.6010103@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TFqe16bjI8+ZpZsFbvt5ag)" X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 3599 This is a multi-part message in MIME format. --Boundary_(ID_TFqe16bjI8+ZpZsFbvt5ag) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT David Kahn wrote: > Raghunath Shenbagam wrote: >>> ok, so the potentially generic sun4v os and apps in the control >>> domain could look for something in the MD to tell if it should >>> use the hw wd or not? >> The application, in this case, is a system management software that >> "pats" >> hw wdt to indicate health. The sys. mgt s/w and Solaris are oblivious of >> MD properties. The new MD properties are used internally by HV to >> determine if it should "pat" hw wdt or hv wdt. > That's confusing. The HV itself doesn't do any patting > unless it's told to by the guest. (via the API). Yes, its the application that's responsible for "patting" the wdt. The hv wdt api is in the "patting" path. app(req to "pat") -> Solaris Driver(call hv api) -> HV WDT -> prog. FPGA(if MD prop. defined) -> trigger IPMC intr. Hence, what i meant in my previous comment was: "The new MD properties are used internally by HV API(when called by app/Solaris) to determine if it should "pat" hw wdt or hv wdt". > > It also looks like the guest can't use the HV_WD > if the hw wd timer address property in the MD is > non-zero. hv wdt api changes affect only when called from the control domain. Guess domain can use the hv wdt api as before and can expect the same behavior from hv. Regards, Raghu --Boundary_(ID_TFqe16bjI8+ZpZsFbvt5ag) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT David Kahn wrote:
Raghunath Shenbagam wrote:
ok, so the potentially generic sun4v os and apps in the control
domain could look for something in the MD to tell if it should
use the hw wd or not?
The application, in this case, is a system management software that "pats"
hw wdt to indicate health. The sys. mgt s/w and Solaris are oblivious of
MD properties. The new MD properties are used internally by HV to
determine if it should "pat" hw wdt or hv wdt.
That's confusing. The HV itself doesn't do any patting
unless it's told to by the guest. (via the API).
Yes, its the application that's responsible for "patting" the wdt.
The hv wdt api is in the "patting" path.

   app(req to "pat") -> Solaris Driver(call hv api) -> HV WDT -> prog. FPGA(if MD prop. defined) -> trigger IPMC intr.

Hence, what i meant in my previous comment was:
 "The new MD properties are used internally by HV API(when called by app/Solaris)
to determine if it should "pat" hw wdt or hv wdt".


It also looks like the guest can't use the HV_WD
if the hw wd timer address property in the MD is
non-zero.
hv wdt api changes affect only when called from the control domain.
Guess domain can use the hv wdt api as before and can expect the
same behavior from hv.

Regards,
Raghu
--Boundary_(ID_TFqe16bjI8+ZpZsFbvt5ag)-- From sacadmin Thu Feb 21 18:45:35 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2jYx3011623 for ; Thu, 21 Feb 2008 18:45:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1M2jOxv013224; Fri, 22 Feb 2008 10:45:33 +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-3.04 (built Jul 15 2005)) id <0JWM0030DCZXQP00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 18:45:33 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM001KVCZW5920@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 18:45:32 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M2jWJ1003171; Thu, 21 Feb 2008 18:45:32 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2jVAs078854; Thu, 21 Feb 2008 18:45:31 -0800 (PST) Date: Thu, 21 Feb 2008 18:45:31 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE3593.6010103@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE374B.5020203@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 625 Raghunath Shenbagam wrote: >> It also looks like the guest can't use the HV_WD >> if the hw wd timer address property in the MD is >> non-zero. > hv wdt api changes affect only when called from the control domain. > Guess domain can use the hv wdt api as before and can expect the > same behavior from hv. Yes, I understood that. The guest is the OS in any domain. Certain APIs will fail if they aren't called from the control domain which is also a guest domain. It just has extra privileges that are extended to the guest running in the control domain. Everything running above the HV is a running as a guest. -David From sacadmin Thu Feb 21 18:52:10 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M2qAO0011655 for ; Thu, 21 Feb 2008 18:52:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1M2q8xM018396; Thu, 21 Feb 2008 18:52:10 -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 <0JWM00D13DAWPM00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:52:08 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00CLBDAVWV00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 18:52:07 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1M2q7c7027290; Thu, 21 Feb 2008 18:52:07 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00701D85Y500@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 18:52:07 -0800 (PST) Received: from [192.168.0.3] ([71.141.98.116]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM007HMDAVZZ00@fe-sfbay-10.sun.com>; Thu, 21 Feb 2008 18:52:07 -0800 (PST) Date: Thu, 21 Feb 2008 18:52:15 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE322E.1020208@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com, Tycho Nightingale , Greg Onufer , Arun Kumar Rao Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE38DF.80404@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE322E.1020208@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1358 David Kahn wrote: > Raghu, > > The more I think about this, the less I like > overloading the current hv wd API. > > It should be relatively simple to define > a new API for the hw wd that can coexist > with the hv wd. That API can be in a new > API group, and negotiation for it could fail > on existing systems, and succeed on new > systems if the hw wd is present. Or it could > succeed if the API exists, and return ENOTSUPPORTED > or some other error code if the hw wd doesn't > exist. Presented both the options(a new api or overloading current api) to hv team. The concenses were to go with overloading hv wdt api. I've cc-ed Tycho, Greg and Arun who can provide better justification for selecting this implementation choice. > > If the goal is to make this a generic feature > supported by sun4v, that's the right way to > do it. (and I think that's what the goal > should be.) The intent is to keep this generic across all sun4v platforms(and perhaps the most compelling reason to overload hv wdt api). I don't know enough about other sun4v platforms with external(outside the host) wdt to understand how much this would be useful. > > I'm also confused about the bit mask > in the document. Is it a mask or a value? > Is the address a physical address? I guess > it would have to be a physical address. Jack, can you please comment? Thanks, Raghu From sacadmin Thu Feb 21 19:20:22 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M3KLe5012095 for ; Thu, 21 Feb 2008 19:20:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1M3KDAB025198; Fri, 22 Feb 2008 11:20:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWM00F07ELU6500@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 19:20:18 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00CTGELTWS10@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 19:20:18 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1M3KHnf028143; Thu, 21 Feb 2008 19:20:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00B01EHCND00@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 19:20:17 -0800 (PST) Received: from [192.168.0.3] ([71.141.123.123]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM004PMELTSJF0@fe-sfbay-09.sun.com>; Thu, 21 Feb 2008 19:20:17 -0800 (PST) Date: Thu, 21 Feb 2008 19:20:25 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE374B.5020203@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE3F79.3030203@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1045 David Kahn wrote: > Raghunath Shenbagam wrote: > >>> It also looks like the guest can't use the HV_WD >>> if the hw wd timer address property in the MD is >>> non-zero. >> hv wdt api changes affect only when called from the control domain. >> Guess domain can use the hv wdt api as before and can expect the >> same behavior from hv. > Yes, I understood that. The guest is the OS in any domain. > > Certain APIs will fail if they aren't called from the control > domain which is also a guest domain. It just has extra > privileges that are extended to the guest running in > the control domain. Everything running above the HV is > a running as a guest. Sorry i misinterpreted your qn. Guest OS(including ctrl domain) can use both hv wdt and hw wdt(but preferably not at the same time, and if they do, we assume (s)he knows what they are doing) with non zero MD prop(hw_wd_addr). The onepager has a table that describe how hw wdt and hv wdt can be used based on "timeout" argument passed to hv api and hw_wd_addr MD definition. Thanks, Raghu From sacadmin Thu Feb 21 19:33:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M3XpaY012172 for ; Thu, 21 Feb 2008 19:33:52 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1M3XgpJ029665; Fri, 22 Feb 2008 11:33:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWM00F05F8CRX00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 19:33:48 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00C0AF8CWQ20@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 19:33:48 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M3XlCA017663; Thu, 21 Feb 2008 19:33:47 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M3Xkvu080194; Thu, 21 Feb 2008 19:33:47 -0800 (PST) Date: Thu, 21 Feb 2008 19:33:47 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE3F79.3030203@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE429B.8080702@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> <47BE3F79.3030203@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 720 Raghunath Shenbagam wrote: >>>> It also looks like the guest can't use the HV_WD >>>> if the hw wd timer address property in the MD is >>>> non-zero. > Guest OS(including ctrl domain) can use both hv wdt and hw wdt(but > preferably not at the same time, and if they do, we assume (s)he knows what > they are doing) with non zero MD prop(hw_wd_addr). The onepager has a table > that describe how hw wdt and hv wdt can be used based on "timeout" > argument passed to hv api and hw_wd_addr MD definition. I saw that same table in the pdf file. I misinterpreted it the first time. !0 timeout value always resets the hv wd. It looks like the definition of the hw wd, doesn't allow the timeout value to be set. -David From sacadmin Thu Feb 21 19:49:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M3n6P3012329 for ; Thu, 21 Feb 2008 19:49:06 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1M3n3Xp064300; Thu, 21 Feb 2008 20:49:06 -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 <0JWM00G03FXULY00@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 19:49:06 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00CDDFXTWV20@nwk-avmta-2.sfbay.sun.com>; Thu, 21 Feb 2008 19:49:05 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1M3n59N028910; Thu, 21 Feb 2008 19:49:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWM00901FUUNE00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 21 Feb 2008 19:49:05 -0800 (PST) Received: from [192.168.0.3] ([71.141.123.123]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWM007CEFXSZZB0@fe-sfbay-10.sun.com>; Thu, 21 Feb 2008 19:49:05 -0800 (PST) Date: Thu, 21 Feb 2008 19:49:12 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE429B.8080702@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47BE4638.6080101@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> <47BE3F79.3030203@sun.com> <47BE429B.8080702@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 884 David Kahn wrote: > > > Raghunath Shenbagam wrote: > >>>>> It also looks like the guest can't use the HV_WD >>>>> if the hw wd timer address property in the MD is >>>>> non-zero. > >> Guest OS(including ctrl domain) can use both hv wdt and hw wdt(but >> preferably not at the same time, and if they do, we assume (s)he >> knows what >> they are doing) with non zero MD prop(hw_wd_addr). The onepager has a >> table >> that describe how hw wdt and hv wdt can be used based on "timeout" >> argument passed to hv api and hw_wd_addr MD definition. > > I saw that same table in the pdf file. I misinterpreted > it the first time. !0 timeout value always resets the > hv wd. It looks like the definition of the hw wd, doesn't > allow the timeout value to be set. That's the recommendation: - set "timeout" to zero to "pat" hw wdt. - !0 "timeout" to "pat"(reset) hv wdt. Regards, Raghu From sacadmin Thu Feb 21 22:54:38 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M6sbAK017358 for ; Thu, 21 Feb 2008 22:54:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M6sWaE029456; Fri, 22 Feb 2008 06:54:36 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWM00905OJ06R00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 22:54:36 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM005TROIZE410@nwk-avmta-1.sfbay.Sun.COM>; Thu, 21 Feb 2008 22:54:35 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1M6sZ2G026020; Thu, 21 Feb 2008 22:54:35 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1M6sYB7084244; Thu, 21 Feb 2008 22:54:34 -0800 (PST) Date: Thu, 21 Feb 2008 22:54:34 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE4638.6080101@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Sunit Jain , Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47BE71AA.8090006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> <47BE3F79.3030203@sun.com> <47BE429B.8080702@sun.com> <47BE4638.6080101@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 452 Raghunath Shenbagam wrote: >> I saw that same table in the pdf file. I misinterpreted >> it the first time. !0 timeout value always resets the >> hv wd. It looks like the definition of the hw wd, doesn't >> allow the timeout value to be set. > That's the recommendation: > - set "timeout" to zero to "pat" hw wdt. > - !0 "timeout" to "pat"(reset) hv wdt. If the HV folks are ok with this, I have no objections. Thanks for the explanation. -David From sacadmin Mon Feb 25 16:41:09 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q0f9pY006178 for ; Mon, 25 Feb 2008 16:41:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1Q0f8MN004043; Mon, 25 Feb 2008 17:41:08 -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 <0JWT00D0HLWJ6F00@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 17:41:07 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00092LWHJT70@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 17:41:05 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q0f5GB020811; Mon, 25 Feb 2008 16:41:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00K01LNWQM00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Mon, 25 Feb 2008 16:41:05 -0800 (PST) Received: from [129.153.85.8] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT009VFLWFBR50@fe-sfbay-10.sun.com>; Mon, 25 Feb 2008 16:41:04 -0800 (PST) Date: Mon, 25 Feb 2008 16:40:59 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE71AA.8090006@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware Arch Cc: Raghunath.Shenbagam@sun.com, Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Message-id: <47C3601B.3080805@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> <47BE3F79.3030203@sun.com> <47BE429B.8080702@sun.com> <47BE4638.6080101@sun.com> <47BE71AA.8090006@sun.com> User-Agent: Thunderbird 2.0.0.12pre (X11/20071231) Status: RO Content-Length: 2110 David Kahn wrote: > > > Raghunath Shenbagam wrote: > >>> I saw that same table in the pdf file. I misinterpreted >>> it the first time. !0 timeout value always resets the >>> hv wd. It looks like the definition of the hw wd, doesn't >>> allow the timeout value to be set. >> That's the recommendation: >> - set "timeout" to zero to "pat" hw wdt. >> - !0 "timeout" to "pat"(reset) hv wdt. > > If the HV folks are ok with this, I have > no objections. > > Thanks for the explanation. > So, how do one stop the Hardware timer? The API calls this out but I don't think that's how this API should behave. Also, how does one set time-out value for a Hardware timer? These are sun4v APIs supported by Hypervisor. The over loading may work for a one or more platforms but it may not always work in all cases in future. We are defining sun4v APIs which by definition needs to be generic APIs and not tied to a particular HW implementation. It may be the right thing to overload, which I don't see, but an explanation on reasons to overload vs creating a new set of APIs for Hardware APIs is important for me to understand. With new set of APIs. you have ability to set time-out value, or stop timers. If HW does not allow setting or stopping timer then those actions can be ignored in those cases. This can be documented and be part of the specification. This way, I think, these APIs can be more complete and extensible. Further, I don't like the fact that this API behaves differently based on a MD property. I don't think any other APIs behave this way (controls two different functions based on certain MD property). I may be wrong here but if there are such APIs then please give me an example of it. IMO, overloading of APIs is confusing and makes the interfaces less extensible for future platforms. There is one typo in the PDF file, in 6th paragraph of section 10.1.6, ot -> to. -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Mon Feb 25 16:58:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q0wfmd006699 for ; Mon, 25 Feb 2008 16:58:41 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q0waqj017804; Tue, 26 Feb 2008 00:58:40 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00407MPPZU00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 16:58:37 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00J4NMPPYK60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 16:58:37 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q0wYnZ022302; Mon, 25 Feb 2008 16:58:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00701MIZ8H00@fe-sfbay-09.sun.com> (original mail from Jack.Bochsler@Sun.COM); Mon, 25 Feb 2008 16:58:35 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT00IG6MP31XE0@fe-sfbay-09.sun.com>; Mon, 25 Feb 2008 16:58:16 -0800 (PST) Date: Mon, 25 Feb 2008 16:58:12 -0800 From: Jack.Bochsler@sun.com Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE38DF.80404@sun.com> Sender: Jack.Bochsler@sun.com To: Raghunath.Shenbagam@sun.com Cc: David Kahn , Sunit Jain , Firmware Arch , atca-wdt-dev@sun.com, Tycho Nightingale , Greg Onufer , Arun Kumar Rao Message-id: <47C36424.1010002@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms050306060908020904010502; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE322E.1020208@sun.com> <47BE38DF.80404@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 8034 --------------ms050306060908020904010502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 1) Sorry for not replying earlier - ALL of this mail thread was getting caught in an errant mail filter. I wasn't even aware that the case had been submitted. Hitu stopped by and mentioned that I hadn't replied to the mail, if he hadn't, I would have remained blissfully unaware... 2) Comment below. Raghunath Shenbagam wrote the following on 02/21/08 18:52: > David Kahn wrote: >> Raghu, >> >> The more I think about this, the less I like >> overloading the current hv wd API. >> >> It should be relatively simple to define >> a new API for the hw wd that can coexist >> with the hv wd. That API can be in a new >> API group, and negotiation for it could fail >> on existing systems, and succeed on new >> systems if the hw wd is present. Or it could >> succeed if the API exists, and return ENOTSUPPORTED >> or some other error code if the hw wd doesn't >> exist. > Presented both the options(a new api or overloading current api) > to hv team. The concenses were to go with overloading hv wdt api. > I've cc-ed Tycho, Greg and Arun who can provide better justification > for selecting this implementation choice. >> >> If the goal is to make this a generic feature >> supported by sun4v, that's the right way to >> do it. (and I think that's what the goal >> should be.) > The intent is to keep this generic across all > sun4v platforms(and perhaps the most compelling > reason to overload hv wdt api). I don't know > enough about other sun4v platforms with > external(outside the host) wdt to understand how much > this would be useful. >> >> I'm also confused about the bit mask >> in the document. Is it a mask or a value? >> Is the address a physical address? I guess >> it would have to be a physical address. > Jack, can you please comment? > There are two components that define this and presumably future WD timer implementations: 1) An address to write, to pat the Watchdog value The api-wdog.pdf document explains this as: "The hw_wd_address property defines the physical address (PA) to which the Hypervisor must write in order to pat the HW_WD watchdog timer." It looks like this information should be duplicated in the table for clarity, I will do so. 2) A magic value to write to the above location to pat the Watchdog The magic value to be written requires (in this case) a specific bit location to trigger the hardware. Although it isn't really a bitmask, the value is just a hardware implementation specific magic value and that may presumably vary between hardware WDT implementations. This value was originally describe to me as a bitmask and the phrase leaked into the description. I thought I had fixed all of the references, but clearly missed one. The api-wdog.pdf table entry currently states: A 64-bit unsigned integer defining a *bit-mask* necessary to write to the address specified by hw_wd_address in order to 'pat' a hardware based watchdog timer. and should be updated to say: A 64-bit unsigned integer defining a *hardware implementation specific value* necessary to write to the address specified by hw_wd_address in order to 'pat' a hardware based watchdog timer. Apologies for the lag, jack --------------ms050306060908020904010502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyNjAwNTgxMlowIwYJKoZIhvcNAQkEMRYEFDMO rv80y6MHUFWG8KzyktAtl0H2MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQA6syEYPY9cdjr1HgISGQySoBKwagdWA2aSXRvoYSGOBrb3i+mk 67Yyt80VSf/gM4GBkYAPPOKRELuzO0rtbYzeApCbfNKbMuNyuu0VALjQqHlg7eRGIWbBcysf bIxut53zyb72l9zoa+k90J9rhJ/uUqujAAsce6cog3peDDTiRBenDDb9J4LdpLntE8EMApTO VxI+W4dPoaopjjvQuvkOIqx97DniQZ/HFZG+vfjs4es2qDIe5xIaKNjKCPC0I6JRJEGhhJju lS6DAP+196WPkbAbKL7KzLhYDs+ntu752pwxcYPuQoSjc3a/PYV6br8J4fzl3eqhap4wmLD5 AdqhAAAAAAAA --------------ms050306060908020904010502-- From sacadmin Mon Feb 25 17:08:42 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q18faA006805 for ; Mon, 25 Feb 2008 17:08:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1Q18eme022070; Tue, 26 Feb 2008 09:08:41 +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-3.04 (built Jul 15 2005)) id <0JWT00601N6G6000@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 17:08:40 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00J8IN6FYP40@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 17:08:39 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q18ddT023089; Mon, 25 Feb 2008 17:08:39 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00401N26OW00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Mon, 25 Feb 2008 17:08:39 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT009Z8N6EBRF0@fe-sfbay-10.sun.com>; Mon, 25 Feb 2008 17:08:39 -0800 (PST) Date: Mon, 25 Feb 2008 17:08:38 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C3601B.3080805@Sun.COM> Sender: Raghunath.Shenbagam@sun.com To: Hitendra Zhangada Cc: Firmware Arch , Jack.Bochsler@sun.com, atca-wdt-dev@sun.com, Tycho Nightingale , Greg Onufer , Arun Kumar Rao Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C36696.3020506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> <47BE3F79.3030203@sun.com> <47BE429B.8080702@sun.com> <47BE4638.6080101@sun.com> <47BE71AA.8090006@sun.com> <47C3601B.3080805@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2362 Hitendra Zhangada wrote: > David Kahn wrote: >> Raghunath Shenbagam wrote: >>>> I saw that same table in the pdf file. I misinterpreted >>>> it the first time. !0 timeout value always resets the >>>> hv wd. It looks like the definition of the hw wd, doesn't >>>> allow the timeout value to be set. >>> That's the recommendation: >>> - set "timeout" to zero to "pat" hw wdt. >>> - !0 "timeout" to "pat"(reset) hv wdt. >> If the HV folks are ok with this, I have >> no objections. >> >> Thanks for the explanation. > So, how do one stop the Hardware timer? The API calls this > out but I don't think that's how this API should behave. The hardware watchdog is setup/disabled using IPMI messages. Please refer onepager section 4.1 and reference material listed in section 5.b for more details on hw wdt setup/disable. > > Also, how does one set time-out value for a Hardware timer? During hw wdt setup. > > These are sun4v APIs supported by Hypervisor. The over > loading may work for a one or more platforms but it may not > always work in all cases in future. We are defining sun4v > APIs which by definition needs to be generic APIs and not > tied to a particular HW implementation. The API itself has not changed. On platforms without these MDs, it behaves like its defined today. Hence, no impact on future or current platforms that does not have hw wdt. > It may be the right thing to overload, which I don't see, > but an explanation on reasons to overload vs creating a > new set of APIs for Hardware APIs is important for me Jack can describe the reasoning better. I've cc-ed Tycho/Greg/Arun for any expert comments. > to understand. With new set of APIs. you have ability > to set time-out value, or stop timers. If HW does not allow > setting or stopping timer then those actions can be ignored > in those cases. This can be documented and be part of the > specification. This way, I think, these APIs can be more > complete and extensible. Again, i'll let HV team to address. > > Further, I don't like the fact that this API behaves differently > based on a MD property. I don't think any other APIs > behave this way (controls two different functions based on > certain MD property). I may be wrong here but if there > are such APIs then please give me an example of it. I don't know of an eg. either, but can you tell me why its bad? /Raghu From sacadmin Mon Feb 25 17:11:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q1BgJj006819 for ; Mon, 25 Feb 2008 17:11:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1Q1BeE5009797; Mon, 25 Feb 2008 18:11:41 -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-3.04 (built Jul 15 2005)) id <0JWT0060RNBGGW00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 17:11:40 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00JUKNBFYK60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 17:11:39 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q1BdRW023324; Mon, 25 Feb 2008 17:11:39 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00701N87ER00@fe-sfbay-10.sun.com> (original mail from Jack.Bochsler@Sun.COM); Mon, 25 Feb 2008 17:11:39 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT007MSNBEKH00@fe-sfbay-10.sun.com>; Mon, 25 Feb 2008 17:11:38 -0800 (PST) Date: Mon, 25 Feb 2008 17:11:34 -0800 From: Jack.Bochsler@sun.com Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C3601B.3080805@Sun.COM> Sender: Jack.Bochsler@sun.com To: Hitendra Zhangada Cc: Firmware Arch , Raghunath.Shenbagam@sun.com, atca-wdt-dev@sun.com Message-id: <47C36746.1070403@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms010702090502080107020802; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE2F92.6030300@sun.com> <47BE3593.6010103@sun.com> <47BE374B.5020203@sun.com> <47BE3F79.3030203@sun.com> <47BE429B.8080702@sun.com> <47BE4638.6080101@sun.com> <47BE71AA.8090006@sun.com> <47C3601B.3080805@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 7497 --------------ms010702090502080107020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hitendra Zhangada wrote the following on 02/25/08 16:40: > David Kahn wrote: >> >> >> Raghunath Shenbagam wrote: >> >>>> I saw that same table in the pdf file. I misinterpreted >>>> it the first time. !0 timeout value always resets the >>>> hv wd. It looks like the definition of the hw wd, doesn't >>>> allow the timeout value to be set. >>> That's the recommendation: >>> - set "timeout" to zero to "pat" hw wdt. >>> - !0 "timeout" to "pat"(reset) hv wdt. >> >> If the HV folks are ok with this, I have >> no objections. >> >> Thanks for the explanation. >> > > So, how do one stop the Hardware timer? The API calls this > out but I don't think that's how this API should behave. > > Also, how does one set time-out value for a Hardware timer? > This is the 3rd WDT that I have worked with - all have been fixed period, but that may reflect more my limited experience than reality. > These are sun4v APIs supported by Hypervisor. The over > loading may work for a one or more platforms but it may not > always work in all cases in future. We are defining sun4v > APIs which by definition needs to be generic APIs and not > tied to a particular HW implementation. > > It may be the right thing to overload, which I don't see, > but an explanation on reasons to overload vs creating a > new set of APIs for Hardware APIs is important for me > to understand. With new set of APIs. you have ability > to set time-out value, or stop timers. If HW does not allow > setting or stopping timer then those actions can be ignored > in those cases. This can be documented and be part of the > specification. This way, I think, these APIs can be more > complete and extensible. > > Further, I don't like the fact that this API behaves differently > based on a MD property. I don't think any other APIs > behave this way (controls two different functions based on > certain MD property). I may be wrong here but if there > are such APIs then please give me an example of it. > > IMO, overloading of APIs is confusing and makes the > interfaces less extensible for future platforms. > > There is one typo in the PDF file, in 6th paragraph of > section 10.1.6, ot -> to. > Fixed. Also caught "Timout" a paragraph up. It would be possible to reserve the last line of the table below (from api-wdog.pdf) to support disabling a future implementation of a HW_WD timer, rather then replicating the behavior of the second row. timeout hw_wd_address HV_WD HW_WD 0 0 disable nop !0 0 reset nop 0 defined disable reset !0 defined reset nop I will let the ATCA HW team address the other questions. jack --------------ms010702090502080107020802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyNjAxMTEzNFowIwYJKoZIhvcNAQkEMRYEFDz/ uD0QmpZxF/dZAWcEPgBd0GFNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQCX1TZOgEMgXYAPwvGtu7x3hhgsKsh4aW+4oodidcphkoDwdj51 gUSc1RLs653mFeHQxuqCuSITw1c4I1Zhy7cSyUVZybAtsPGKYoHK6pnLDfyM4bHi9Kcw9YUj mpGoL0aN0oxE6zhCG2GMCO12s/EiFKgBtr8+RqL++GB8uN1WNQ1rBEpPv6qM8WjJJh2l8gSh wZNoUw5DwCtr+mF6l/3/R+KKbJwM3gie+Pb7h6DeOLgtjyAmU0QxKASI7ZtuTVES2z8oMb/A XleGKhsQA2gMwz0U9zX0Htb0SKIVFXSfK+apmHLuQkRTEnVAzIoUHcwY3lGHbmmUHHPRiUpY sOnmAAAAAAAA --------------ms010702090502080107020802-- From sacadmin Mon Feb 25 17:22:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q1MVIm006873 for ; Mon, 25 Feb 2008 17:22:32 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q1MMFS026096; Tue, 26 Feb 2008 01:22:31 GMT 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 <0JWT00J0NNTFT100@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Feb 2008 17:22:27 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00DALNTF8L80@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Feb 2008 17:22:27 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q1MRUn062214; Mon, 25 Feb 2008 17:22:27 -0800 (PST) Received: from [192.168.0.9] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1Q1MP9Q013785; Mon, 25 Feb 2008 17:22:25 -0800 (PST) Date: Mon, 25 Feb 2008 17:22:25 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer To: Jack.Bochsler@sun.com Cc: Hitendra Zhangada , Firmware Arch , Raghunath.Shenbagam@sun.com, atca-wdt-dev@sun.com Message-id: <47C369D1.3090305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 429 Jack.Bochsler@sun.com wrote: > This is the 3rd WDT that I have worked with - all have been fixed > period, but that may reflect more my limited experience than reality. ok, so even if it's a fixed period, how is the generic software supposed to know what that fixed period is? With the overloaded interface, the timeout value isn't really used in the HW WD case, right? (It doesn't actually define a timeout value). -David From sacadmin Mon Feb 25 17:33:22 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q1XMvu006949 for ; Mon, 25 Feb 2008 17:33:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1Q1XHw2000666; Mon, 25 Feb 2008 17:33: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 <0JWT00H09OBLB000@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 18:33:21 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT000PVOBJJY90@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 18:33:20 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q1XJY8024986; Mon, 25 Feb 2008 17:33:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00F01NZY9X00@fe-sfbay-09.sun.com> (original mail from Jack.Bochsler@Sun.COM); Mon, 25 Feb 2008 17:33:19 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT00F7YOAYDJC0@fe-sfbay-09.sun.com>; Mon, 25 Feb 2008 17:32:58 -0800 (PST) Date: Mon, 25 Feb 2008 17:32:54 -0800 From: Jack.Bochsler@sun.com Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C369D1.3090305@sun.com> Sender: Jack.Bochsler@sun.com To: David Kahn Cc: Hitendra Zhangada , Firmware Arch , Raghunath.Shenbagam@sun.com, atca-wdt-dev@sun.com Message-id: <47C36C46.9080207@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms070701060107070007040203; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 6019 --------------ms070701060107070007040203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Kahn wrote the following on 02/25/08 17:22: > > > Jack.Bochsler@sun.com wrote: > >> This is the 3rd WDT that I have worked with - all have been fixed >> period, but that may reflect more my limited experience than reality. > > ok, so even if it's a fixed period, how is the generic > software supposed to know what that fixed period is? > > With the overloaded interface, the timeout value isn't > really used in the HW WD case, right? (It doesn't actually > define a timeout value). > Note that at the moment, this is a secret value - HV doesn't know the timeout either, it is purely in the hardware. There *could* be a property providing an address (and size) for HV to read the timeout value, and pass this back to the guest. Not sure if the HW guys are willing/able to do this. This does beg the question though - what if the Guest can't support the heartbeat frequency (too fast)? So this means the query and enable are separate, and the guest shouldn't enable the HW WDT IFF it can't support it. But how does the guest know what it can support? Do we define yet another property to tell the guest? jack --------------ms070701060107070007040203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyNjAxMzI1NFowIwYJKoZIhvcNAQkEMRYEFC9y 6wA5iGkWC5k0DAmHj7wdfjYbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQAZudpCcrCVZ9p5PLPCr+c4UMpDdVNoeik30PDugSEiRfe5Jo0y p6Vf/oZy+tY/HAQj/onZX3Fem3UTSx0Mk/FziBtgKzJ/wCImLFCmDcMpMQ5Ue5HoOBE/BiSB 1dh+e5wkqGzlj/inyqaeOHZd5pQvap7IiH7xnvObxC8Qd5o3e/M7sXrFC3WBlomL4TfKcosY /OTBYOGL9q6nNwBcmsqm+FWd+OrEJk/pHw2Q+ZSD3na/0FiAWtGNhRa6WZ/tO0YIppEm0u2U q2i91AsUDI6vEON6SechD3fkXgAaqohfmhlC8Mgt5XvrncD6MsPtNOhdXlk9K1vbc07zAn/c ObFDAAAAAAAA --------------ms070701060107070007040203-- From sacadmin Mon Feb 25 17:45:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q1jmBJ006986 for ; Mon, 25 Feb 2008 17:45:49 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1Q1jdJ0006327; Tue, 26 Feb 2008 09:45:47 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00K1DOWAPO00@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Feb 2008 17:45:46 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00DFFOW48I90@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Feb 2008 17:45:40 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q1jeMw012585; Mon, 25 Feb 2008 17:45:40 -0800 (PST) Received: from [192.168.0.9] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1Q1jdEQ014351; Mon, 25 Feb 2008 17:45:39 -0800 (PST) Date: Mon, 25 Feb 2008 17:45:39 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C36C46.9080207@Sun.COM> To: Jack.Bochsler@sun.com Cc: Hitendra Zhangada , Firmware Arch , Raghunath.Shenbagam@sun.com, atca-wdt-dev@sun.com Message-id: <47C36F43.5000500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1978 Jack.Bochsler@Sun.COM wrote: > > > David Kahn wrote the following on 02/25/08 17:22: >> >> >> Jack.Bochsler@sun.com wrote: >> >>> This is the 3rd WDT that I have worked with - all have been fixed >>> period, but that may reflect more my limited experience than reality. >> >> ok, so even if it's a fixed period, how is the generic >> software supposed to know what that fixed period is? >> >> With the overloaded interface, the timeout value isn't >> really used in the HW WD case, right? (It doesn't actually >> define a timeout value). >> > Note that at the moment, this is a secret value - HV doesn't > know the timeout either, it is purely in the hardware. > > There *could* be a property providing an address (and size) > for HV to read the timeout value, and pass this back to the > guest. Not sure if the HW guys are willing/able to do this. > > This does beg the question though - what if the Guest can't > support the heartbeat frequency (too fast)? So this means the query > and enable are separate, and the guest shouldn't enable the > HW WDT IFF it can't support it. > > But how does the guest know what it can support? Do we define yet > another property to tell the guest? I think at some point, it's ok to assume that any given hw wd has been designed so that it can actually be functional, so while I think it's necessary for a generic guest to be able to figure out what the trigger period is, we can leave it as an exercise to application programming to figure out how to make sure that it actually calls the API within the correct period. (You could also go further with this. For example, how do you take into account the overhead of all the software in between the application and the hardware?) For everything else you've said, I believe a separate set of interfaces in their own API group would be much better for the HW WD. One interface to get the period, another (set of) interface(s) to enable/pat/disable the hw watchdog timer. -David From sacadmin Mon Feb 25 17:58:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q1wmhY007291 for ; Mon, 25 Feb 2008 17:58:48 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1Q1wZrU011140; Tue, 26 Feb 2008 09:58:47 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00L0BPHY5M00@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Feb 2008 17:58:46 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT00DN3PHX8IA0@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Feb 2008 17:58:45 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q1wj5c026863; Mon, 25 Feb 2008 17:58:45 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00D01PFRPO00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Mon, 25 Feb 2008 17:58:45 -0800 (PST) Received: from [192.168.1.101] ([71.141.105.192]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT005MOPHWLN30@fe-sfbay-10.sun.com>; Mon, 25 Feb 2008 17:58:45 -0800 (PST) Date: Mon, 25 Feb 2008 17:58:57 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C36C46.9080207@Sun.COM> Sender: Raghunath.Shenbagam@sun.com To: Jack.Bochsler@sun.com Cc: David Kahn , Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C37261.50101@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1620 Jack.Bochsler@Sun.COM wrote: > David Kahn wrote the following on 02/25/08 17:22: >> Jack.Bochsler@sun.com wrote: >>> This is the 3rd WDT that I have worked with - all have been fixed >>> period, but that may reflect more my limited experience than reality. >> ok, so even if it's a fixed period, how is the generic >> software supposed to know what that fixed period is? >> >> With the overloaded interface, the timeout value isn't >> really used in the HW WD case, right? (It doesn't actually >> define a timeout value). >> > Note that at the moment, this is a secret value - HV doesn't > know the timeout either, it is purely in the hardware. > > There *could* be a property providing an address (and size) > for HV to read the timeout value, and pass this back to the > guest. Not sure if the HW guys are willing/able to do this. For this project, we require interface to just "pat" the hw wdt. To read the timeout value set, or to enable/disable hw wdt, there are done using other interfaces(IPMI). The HV WDT API in this current form is used only to "pat". If hv interface is required to support enable/disable hw wdt, the hw interface need to be extended to define new set of api. ATCA wdt project does not require hv interface to enable/disable hw wdt. /Raghu > > This does beg the question though - what if the Guest can't > support the heartbeat frequency (too fast)? So this means the query > and enable are separate, and the guest shouldn't enable the > HW WDT IFF it can't support it. > > But how does the guest know what it can support? Do we define yet > another property to tell the guest? > > jack From sacadmin Mon Feb 25 18:01:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q21X5b007399 for ; Mon, 25 Feb 2008 18:01:34 -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 m1Q21Hfd012141; Tue, 26 Feb 2008 10:01:32 +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 <0JWT00J05PMICA00@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 19:01:30 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT000QPPMGK5A0@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 19:01:29 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q21SFK024704; Mon, 25 Feb 2008 18:01:28 -0800 (PST) Received: from [192.168.0.9] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1Q21RB3014584; Mon, 25 Feb 2008 18:01:27 -0800 (PST) Date: Mon, 25 Feb 2008 18:01:27 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C37261.50101@sun.com> To: Raghunath.Shenbagam@sun.com Cc: Jack.Bochsler@sun.com, Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com Message-id: <47C372F7.2060302@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C37261.50101@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 625 Raghunath Shenbagam wrote: > The HV WDT API in this current form is used only to "pat". > If hv interface is required to support enable/disable hw wdt, > the hw interface need to be extended to define new set of api. > ATCA wdt project does not require hv interface to enable/disable > hw wdt. How does it get enabled? I can't just always be enabled. I assume you meant that enable is a side-effect of patting it for the first time. What happens if the guest that's doing the patting goes down? What happens if we reboot the control domain? What happens if we want to debug the guest in the control domain? ... -David From sacadmin Mon Feb 25 19:07:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q37coY009264 for ; Mon, 25 Feb 2008 19:07:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q37b0G004506; Tue, 26 Feb 2008 03:07:37 GMT 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 <0JWT00203SOO2P00@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 20:07:36 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT000YCSONJSD0@brm-avmta-1.central.sun.com>; Mon, 25 Feb 2008 20:07:35 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q37ZxF000090; Mon, 25 Feb 2008 19:07:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00C01SINIY00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Mon, 25 Feb 2008 19:07:35 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT00172SOM9450@fe-sfbay-10.sun.com>; Mon, 25 Feb 2008 19:07:35 -0800 (PST) Date: Mon, 25 Feb 2008 19:07:34 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C372F7.2060302@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Jack.Bochsler@sun.com, Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C38276.4090307@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C37261.50101@sun.com> <47C372F7.2060302@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2091 David Kahn wrote: > Raghunath Shenbagam wrote: >> The HV WDT API in this current form is used only to "pat". >> If hv interface is required to support enable/disable hw wdt, >> the hw interface need to be extended to define new set of api. >> ATCA wdt project does not require hv interface to enable/disable >> hw wdt. > How does it get enabled? I can't just always be enabled. To provide a little bit of background on the platform: ATCA WDT is part of a platform management (micro)controller(IPMC): ATCA WDT can be: 1) HW WDT Setup: The HW WDT can be Setup by sending an "setup" IPMI command to IPMC. IPMC is not directly accesible by N2 host. The IPMI cmd are sent to ILOM (via ldc channel), and ILOM fwd.s it to IPMC thru' serial interface. 2) HW WDT pat: ATCA WDT can be pat using the same path used to "setup". The is a lot of overhead in this path, this project is to address this overhead. 3) HW WDT disable: Similar to setup, a "disable" IPMI cmd from host to IPMC via ILOM. Now, to answer your qn., the setup does not start the timer, like you mentioned below, the hw watchdog get enabled during the first pat and disabled when an IPMI disable wdt command is sent. Once disabled, subsequent "pat" does not start the timer. > I assume you meant that enable is a side-effect of patting > it for the first time. > > What happens if the guest that's doing the patting goes Only the ctrl domain can pat the hw wdt. If the application is running on a guest domain, the expiry will reset only that domain. > > down? What happens if we reboot the control domain? If application is running on ctrl domain, it does not necessarily reset the whole system. The watchdog can be configured to just "ignore" the timer expiry and send a notification to a system mgt s/w running outside the blade. The system mgt s/w can then attempt to verify if all guests are down(by say ping) and reset the whole system accordingly. > What happens if we want to debug the guest in the > control domain? ... When anyone wants to debug the host, the watchdog had to be stopped. /Raghu From sacadmin Mon Feb 25 20:33:55 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q4XsoZ013028 for ; Mon, 25 Feb 2008 20:33:54 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1Q4XnqD004977; Tue, 26 Feb 2008 12:33:53 +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-3.04 (built Jul 15 2005)) id <0JWT0050DWOER100@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 20:33:50 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT004HAWOEG810@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 20:33:50 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q4XnJt021141; Mon, 25 Feb 2008 20:33:49 -0800 (PST) Received: from [192.168.0.9] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1Q4Xm3s016044; Mon, 25 Feb 2008 20:33:48 -0800 (PST) Date: Mon, 25 Feb 2008 20:33:48 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C38276.4090307@Sun.COM> To: Raghunath.Shenbagam@sun.com Cc: Jack.Bochsler@sun.com, Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com Message-id: <47C396AC.9070007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C37261.50101@sun.com> <47C372F7.2060302@sun.com> <47C38276.4090307@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 2104 Raghunath Shenbagam wrote: >> How does it get enabled? I can't just always be enabled. > To provide a little bit of background on the platform: > > ATCA WDT is part of a platform management (micro)controller(IPMC): ATCA WDT > can be: > > 1) HW WDT Setup: The HW WDT can be Setup by sending an "setup" IPMI command > to IPMC. IPMC is not directly accesible by N2 host. The IPMI cmd are sent to > ILOM (via ldc channel), and ILOM fwd.s it to IPMC thru' serial interface. Who does that? ILOM? Via some user interface to enable it? > > 2) HW WDT pat: ATCA WDT can be pat using the same path used to "setup". The > is a lot of overhead in this path, this project is to address this overhead. ok. > > 3) HW WDT disable: Similar to setup, a "disable" IPMI cmd from host to IPMC > via ILOM. And that's also done via the ILOM UI? > > Now, to answer your qn., the setup does not start the timer, like you > mentioned below, the hw watchdog get enabled during the first pat and > disabled when an IPMI disable wdt command is sent. Once disabled, subsequent > "pat" does not start the timer. ok, so that enables it when the system comes up, the control domain boots, and eventually the application comes along and 'starts' it by patting it for the first time. >> What happens if the guest that's doing the patting goes > Only the ctrl domain can pat the hw wdt. If the application is running on a > guest domain, the expiry will reset only that domain. We just had the discussion about the term "guest" last week. Everything is a guest. Certain guest domains have privileges not extended to other domains, such as the guest running in the control domain. I think we all understand that the HV WD API is only available to the control domain. >> >> down? What happens if we reboot the control domain? > If application is running on ctrl domain, it does not necessarily reset the > whole system. The watchdog can be configured to just "ignore" the timer > expiry and send a notification to a system mgt s/w running outside the blade. ok, how is that done? Is that done externally? Thanks, David From sacadmin Mon Feb 25 21:20:08 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q5K7HB013719 for ; Mon, 25 Feb 2008 21:20:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q5JxgV014591; Tue, 26 Feb 2008 05:20:06 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWT00A0HYTGUZ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 21:20:04 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWT004KKYTGG890@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 21:20:04 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1Q5K47s028733; Mon, 25 Feb 2008 21:20:04 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWT00101YMCWT00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Mon, 25 Feb 2008 21:20:04 -0800 (PST) Received: from [192.168.1.101] ([71.141.105.192]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWT00K1TYTFQMC0@fe-sfbay-10.sun.com>; Mon, 25 Feb 2008 21:20:04 -0800 (PST) Date: Mon, 25 Feb 2008 21:20:16 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C396AC.9070007@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Jack.Bochsler@sun.com, Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C3A190.7070701@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C37261.50101@sun.com> <47C372F7.2060302@sun.com> <47C38276.4090307@Sun.COM> <47C396AC.9070007@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 2591 David Kahn wrote: > > > Raghunath Shenbagam wrote: > >>> How does it get enabled? I can't just always be enabled. >> To provide a little bit of background on the platform: >> >> ATCA WDT is part of a platform management (micro)controller(IPMC): >> ATCA WDT >> can be: >> >> 1) HW WDT Setup: The HW WDT can be Setup by sending an "setup" IPMI >> command >> to IPMC. IPMC is not directly accesible by N2 host. The IPMI cmd are >> sent to >> ILOM (via ldc channel), and ILOM fwd.s it to IPMC thru' serial >> interface. > Who does that? ILOM? Via some user interface to enable it? 1) Application open Solaris IPMI driver and send wd setup cmd. 2) Solaris IPMI driver sends the message over ldc channel to iLOM 3) ILOM recognize wdt command to IPMC and fwd(automatically) to IPMC. 4) IPMC initialize wdt. >> >> 2) HW WDT pat: ATCA WDT can be pat using the same path used to >> "setup". The >> is a lot of overhead in this path, this project is to address this >> overhead. > ok. >> >> 3) HW WDT disable: Similar to setup, a "disable" IPMI cmd from host >> to IPMC >> via ILOM. > > And that's also done via the ILOM UI? Same way application sends "setup" command to IPMC. > >> >> Now, to answer your qn., the setup does not start the timer, like you >> mentioned below, the hw watchdog get enabled during the first pat and >> disabled when an IPMI disable wdt command is sent. Once disabled, >> subsequent >> "pat" does not start the timer. > > ok, so that enables it when the system comes up, the > control domain boots, and eventually the application > comes along and 'starts' it by patting it for the first > time. > Yes. >>> What happens if the guest that's doing the patting goes >> Only the ctrl domain can pat the hw wdt. If the application is >> running on a >> guest domain, the expiry will reset only that domain. > > We just had the discussion about the term "guest" > last week. > > Everything is a guest. Certain guest domains have > privileges not extended to other domains, such as > the guest running in the control domain. > > I think we all understand that the HV WD API > is only available to the control domain. > OK. I mentioned it to bring out the distinction in behavior when wdt expired. >>> >>> down? What happens if we reboot the control domain? >> If application is running on ctrl domain, it does not necessarily >> reset the >> whole system. The watchdog can be configured to just "ignore" the timer >> expiry and send a notification to a system mgt s/w running outside >> the blade. > > ok, how is that done? Is that done externally? Yes. Thanks, Raghu From sacadmin Tue Feb 26 09:50:30 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QHoUGg005856 for ; Tue, 26 Feb 2008 09:50:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QHoSj9001453; Tue, 26 Feb 2008 10:50:29 -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 <0JWU00J0JXK4QU00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Feb 2008 09:50:28 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00G9FXK2RG60@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Feb 2008 09:50:27 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QHoQ83003006; Tue, 26 Feb 2008 09:50:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00101X82KT00@fe-sfbay-09.sun.com> (original mail from Jack.Bochsler@Sun.COM); Tue, 26 Feb 2008 09:50:26 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU003HNXJQVDB0@fe-sfbay-09.sun.com>; Tue, 26 Feb 2008 09:50:14 -0800 (PST) Date: Tue, 26 Feb 2008 09:50:11 -0800 From: Jack.Bochsler@sun.com Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C36C46.9080207@Sun.COM> Sender: Jack.Bochsler@sun.com To: Raghunath.Shenbagam@sun.com Cc: Firmware Arch , atca-wdt-dev@sun.com Message-id: <47C45153.1080009@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms090802020103060006010203; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 5973 --------------ms090802020103060006010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jack.Bochsler@Sun.COM wrote the following on 02/25/08 17:32: > > > David Kahn wrote the following on 02/25/08 17:22: >> >> >> Jack.Bochsler@sun.com wrote: >> >>> This is the 3rd WDT that I have worked with - all have been fixed >>> period, but that may reflect more my limited experience than reality. >> >> ok, so even if it's a fixed period, how is the generic >> software supposed to know what that fixed period is? >> >> With the overloaded interface, the timeout value isn't >> really used in the HW WD case, right? (It doesn't actually >> define a timeout value). >> > Note that at the moment, this is a secret value - HV doesn't > know the timeout either, it is purely in the hardware. > > There *could* be a property providing an address (and size) > for HV to read the timeout value, and pass this back to the > guest. Not sure if the HW guys are willing/able to do this. > Regarding determination of the WDT period - is this still a requirement, that the HV provide the period to the Guest? I didn't see a response from the HW side - whether this can be done. jack --------------ms090802020103060006010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyNjE3NTAxMVowIwYJKoZIhvcNAQkEMRYEFAuY uk7DtH8m97mXX65Y71Fm8+wSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQCvX7f00cQRKQIolm6ss9tfwFWt782zI8U1RqV6w2vSRsMMyA0G lf1ucMeToJjWCxmHBo2LvPHFS5N/AwJ9ctZVQ5eRpAuqf/CByuO9A8w1AyOEFIVJioy8KLtw VJbN6stEzIzCBvekKx2kH84m7jcU0z7KFp84fBjocxY4iisMcGOaULrLT1eqSWvCnE67uRuT SAwdDkSE8lM3POLbhMqESwVnQPjkzuJghUDkINqEOf+cjr5964C4gkqPmz0zpbKdTREIOCt/ ydkBhrJDHJr5cL86511vjbM3qChPfboXp/iA3VvvXHsZCgOc+5oePXD4KSMmAb0S1CBOSnfF GX0HAAAAAAAA --------------ms090802020103060006010203-- From sacadmin Tue Feb 26 10:03:28 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QI3RA5006796 for ; Tue, 26 Feb 2008 10:03:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QI3Qah005357; Tue, 26 Feb 2008 11:03:27 -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-3.04 (built Jul 15 2005)) id <0JWU00M09Y5QKS00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 10:03:26 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00LF2Y5PRO00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 10:03:26 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QI3Psx004853; Tue, 26 Feb 2008 10:03:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00901X1F6F00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Tue, 26 Feb 2008 10:03:25 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU0096RY59FQD0@fe-sfbay-10.sun.com>; Tue, 26 Feb 2008 10:03:11 -0800 (PST) Date: Tue, 26 Feb 2008 10:03:09 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C45153.1080009@Sun.COM> Sender: Raghunath.Shenbagam@sun.com To: Jack.Bochsler@sun.com Cc: Firmware Arch , atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C4545D.9000806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1268 Jack.Bochsler@Sun.COM wrote: > > > Jack.Bochsler@Sun.COM wrote the following on 02/25/08 17:32: >> >> >> David Kahn wrote the following on 02/25/08 17:22: >>> >>> >>> Jack.Bochsler@sun.com wrote: >>> >>>> This is the 3rd WDT that I have worked with - all have been fixed >>>> period, but that may reflect more my limited experience than reality. >>> >>> ok, so even if it's a fixed period, how is the generic >>> software supposed to know what that fixed period is? >>> >>> With the overloaded interface, the timeout value isn't >>> really used in the HW WD case, right? (It doesn't actually >>> define a timeout value). >>> >> Note that at the moment, this is a secret value - HV doesn't >> know the timeout either, it is purely in the hardware. >> >> There *could* be a property providing an address (and size) >> for HV to read the timeout value, and pass this back to the >> guest. Not sure if the HW guys are willing/able to do this. >> > Regarding determination of the WDT period - is this still a requirement, > that the HV provide the period to the Guest? > > I didn't see a response from the HW side - whether this can be done. Sorry, though i addressed this qn.. WDT period set(or timeout left during "pat") is not a requirement for this project. /Raghu From sacadmin Tue Feb 26 10:13:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QIDUeW008178 for ; Tue, 26 Feb 2008 10:13:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1QIDQ6U017755; Wed, 27 Feb 2008 02:13:29 +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-3.04 (built Jul 15 2005)) id <0JWU00001YMGD600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 10:13:28 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00LDOYMGRT10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 10:13:28 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QIDS1m006360; Tue, 26 Feb 2008 10:13:28 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00I01YF55U00@fe-sfbay-09.sun.com> (original mail from Jack.Bochsler@Sun.COM); Tue, 26 Feb 2008 10:13:28 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU003G4YMFH180@fe-sfbay-09.sun.com>; Tue, 26 Feb 2008 10:13:27 -0800 (PST) Date: Tue, 26 Feb 2008 10:13:24 -0800 From: Jack.Bochsler@sun.com Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C4545D.9000806@Sun.COM> Sender: Jack.Bochsler@sun.com To: Raghunath.Shenbagam@sun.com Cc: Firmware Arch , atca-wdt-dev@sun.com Message-id: <47C456C4.70200@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms070406050402030600020506; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> <47C4545D.9000806@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 6700 --------------ms070406050402030600020506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Raghunath Shenbagam wrote the following on 02/26/08 10:03: > Jack.Bochsler@Sun.COM wrote: >> >> >> Jack.Bochsler@Sun.COM wrote the following on 02/25/08 17:32: >>> >>> >>> David Kahn wrote the following on 02/25/08 17:22: >>>> >>>> >>>> Jack.Bochsler@sun.com wrote: >>>> >>>>> This is the 3rd WDT that I have worked with - all have been fixed >>>>> period, but that may reflect more my limited experience than reality. >>>> >>>> ok, so even if it's a fixed period, how is the generic >>>> software supposed to know what that fixed period is? >>>> >>>> With the overloaded interface, the timeout value isn't >>>> really used in the HW WD case, right? (It doesn't actually >>>> define a timeout value). >>>> >>> Note that at the moment, this is a secret value - HV doesn't >>> know the timeout either, it is purely in the hardware. >>> >>> There *could* be a property providing an address (and size) >>> for HV to read the timeout value, and pass this back to the >>> guest. Not sure if the HW guys are willing/able to do this. >>> >> Regarding determination of the WDT period - is this still a requirement, >> that the HV provide the period to the Guest? >> >> I didn't see a response from the HW side - whether this can be done. > Sorry, though i addressed this qn.. > > WDT period set(or timeout left during "pat") is not a requirement for > this project. > But I believe the root problem is: How does Solaris know the correct WDT period? With the HV WDT, Solaris specifies this value to the WDT. With the Monza WDT, the value is 100mS - but is this hardwired into Solaris? If not, where is Solaris getting the value? What happens with the next HW WDT that has a period of 85mS? I agree that this will meet the immediate needs, my concern is not having to re-whack all this for the next HW WDT. jack --------------ms070406050402030600020506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyNjE4MTMyNFowIwYJKoZIhvcNAQkEMRYEFP7O TCwNTtrCG8DAzo+97Fnhsuo7MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQBI8z1uUT6+JfalFpLXQeuoo9EjvpEj9qbxPlBtQj+Hp/DyDioP s8S6IXS72g34/AWMLTTyCsFFNbqivakpkERoqYJd1QHajFC+mro4tqrjTrZUknvomqEZI5xe SsXsUUJrqzxLfMJHswQz8EaIQuPWxdPX9vi9tAPj+fMEnReADcYiMU9MSatnwfjwmUmdJQSO kKWreB3/Xgl2Zb8h6AGJXzBbH2Kq6sGJMjFSWKYay2ffF4FflAjM4tHuZlgrHkkdyIlejtaV /mi9V7d68QbFv1+F85vEAxn+R+XdJojw8zZRMmDy6AWw2mZQb8cGnrj433KOeY5z1U0PXL+Y q2k9AAAAAAAA --------------ms070406050402030600020506-- From sacadmin Tue Feb 26 10:43:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QIh0j0009429 for ; Tue, 26 Feb 2008 10:43:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1QIgvtn029693; Wed, 27 Feb 2008 02:42:59 +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-3.04 (built Jul 15 2005)) id <0JWU0020XZZNZZ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 10:42:59 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00L1IZZKRO30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 10:42:56 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QIguPp011152; Tue, 26 Feb 2008 10:42:56 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00901X1F6F00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Tue, 26 Feb 2008 10:42:56 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWU006A3ZZ73T10@fe-sfbay-10.sun.com>; Tue, 26 Feb 2008 10:42:45 -0800 (PST) Date: Tue, 26 Feb 2008 10:42:43 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C456C4.70200@Sun.COM> Sender: Raghunath.Shenbagam@sun.com To: Jack.Bochsler@sun.com Cc: Firmware Arch , atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C45DA3.90900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> <47C4545D.9000806@Sun.COM> <47C456C4.70200@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2822 Jack.Bochsler@Sun.COM wrote: > > > Raghunath Shenbagam wrote the following on 02/26/08 10:03: >> Jack.Bochsler@Sun.COM wrote: >>> >>> >>> Jack.Bochsler@Sun.COM wrote the following on 02/25/08 17:32: >>>> >>>> >>>> David Kahn wrote the following on 02/25/08 17:22: >>>>> >>>>> >>>>> Jack.Bochsler@sun.com wrote: >>>>> >>>>>> This is the 3rd WDT that I have worked with - all have been fixed >>>>>> period, but that may reflect more my limited experience than >>>>>> reality. >>>>> >>>>> ok, so even if it's a fixed period, how is the generic >>>>> software supposed to know what that fixed period is? >>>>> >>>>> With the overloaded interface, the timeout value isn't >>>>> really used in the HW WD case, right? (It doesn't actually >>>>> define a timeout value). >>>>> >>>> Note that at the moment, this is a secret value - HV doesn't >>>> know the timeout either, it is purely in the hardware. >>>> >>>> There *could* be a property providing an address (and size) >>>> for HV to read the timeout value, and pass this back to the >>>> guest. Not sure if the HW guys are willing/able to do this. >>>> >>> Regarding determination of the WDT period - is this still a >>> requirement, >>> that the HV provide the period to the Guest? >>> >>> I didn't see a response from the HW side - whether this can be done. >> Sorry, though i addressed this qn.. >> >> WDT period set(or timeout left during "pat") is not a requirement for >> this project. >> > But I believe the root problem is: > How does Solaris know the correct WDT period? > > With the HV WDT, Solaris specifies this value to the WDT. > With the Monza WDT, the value is 100mS - but is this hardwired into > Solaris? > If not, where is Solaris getting the value? On Monza platform, ATCA WDT period is programmed by sending IPMI message(cmd) to IPMC over ldc channel. Solaris kernel(like hv) is not aware of this value. Solaris facilitates(like hv), an application running in user land to setup/pat/disable hw wdt. > What happens with the next HW WDT that has a period of 85mS? If application set hw wdt to 85ms, its application's responsibility to pat hw wdt with this period. We are reducing the overhead in the kernel and hv so the application can pat successfully with short timeout value. > I agree that this will meet the immediate needs, my concern is > not having to re-whack all this for the next HW WDT. Agreed, this project focus only in optimizing the "patting" path. If hv apis were to be extended to support setup/enable/disable of hw wdt, hv interface should be extended to define a new set of hw wdt apis. It can continue to use the current api to "pat". Setup(enable)/disable hv api is outside the scope of this project. Having said that, we have to make sure(thru' this review) the proposed changes accommodate for future extension. /Raghu From sacadmin Tue Feb 26 11:26:06 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QJQ6qm010680 for ; Tue, 26 Feb 2008 11:26:06 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1QJPxiw004837; Tue, 26 Feb 2008 19:26:05 GMT 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 <0JWV00C431ZGVQ00@brm-avmta-1.central.sun.com>; Tue, 26 Feb 2008 12:26:04 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV0048J1ZEURB0@brm-avmta-1.central.sun.com>; Tue, 26 Feb 2008 12:26:03 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QJQ2XD017023; Tue, 26 Feb 2008 11:26:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWV006010MJDR00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Tue, 26 Feb 2008 11:26:02 -0800 (PST) Received: from [129.153.85.8] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWV004BJ1Z3PO90@fe-sfbay-10.sun.com>; Tue, 26 Feb 2008 11:25:51 -0800 (PST) Date: Tue, 26 Feb 2008 11:25:47 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C456C4.70200@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Jack.Bochsler@sun.com Cc: Raghunath.Shenbagam@sun.com, Firmware Arch , atca-wdt-dev@sun.com Message-id: <47C467BB.50509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> <47C4545D.9000806@Sun.COM> <47C456C4.70200@Sun.COM> User-Agent: Thunderbird 2.0.0.12pre (X11/20071231) Status: RO Content-Length: 3718 Jack.Bochsler@Sun.COM wrote: > > > Raghunath Shenbagam wrote the following on 02/26/08 10:03: >> Jack.Bochsler@Sun.COM wrote: >>> >>> >>> Jack.Bochsler@Sun.COM wrote the following on 02/25/08 17:32: >>>> >>>> >>>> David Kahn wrote the following on 02/25/08 17:22: >>>>> >>>>> >>>>> Jack.Bochsler@sun.com wrote: >>>>> >>>>>> This is the 3rd WDT that I have worked with - all have been fixed >>>>>> period, but that may reflect more my limited experience than >>>>>> reality. >>>>> >>>>> ok, so even if it's a fixed period, how is the generic >>>>> software supposed to know what that fixed period is? >>>>> >>>>> With the overloaded interface, the timeout value isn't >>>>> really used in the HW WD case, right? (It doesn't actually >>>>> define a timeout value). >>>>> >>>> Note that at the moment, this is a secret value - HV doesn't >>>> know the timeout either, it is purely in the hardware. >>>> >>>> There *could* be a property providing an address (and size) >>>> for HV to read the timeout value, and pass this back to the >>>> guest. Not sure if the HW guys are willing/able to do this. >>>> >>> Regarding determination of the WDT period - is this still a >>> requirement, >>> that the HV provide the period to the Guest? >>> >>> I didn't see a response from the HW side - whether this can be done. >> Sorry, though i addressed this qn.. >> >> WDT period set(or timeout left during "pat") is not a requirement for >> this project. >> > But I believe the root problem is: > How does Solaris know the correct WDT period? > This is a good question to answer. I think this needs to be in MD similar to the HV WDT design. I also believe we should have a way to stop and set time-out values. As I said earlier if HW does not support this then it can be ignored with an error status. As for what happens when control domain reboots/reset, I think the behavior should be that these WDT be stopped and should only be enabled when SW decides to do so upon reboot. Requiring user to disable timers using UI is not good. What this means is that if a system reboots, lets say PANIC reboot, when user is not around then there is possibility of HW WDT trigger while in OpenBoot, Solaris boot or in Solaris before Solaris starts patting the timer. Lastly, I still haven't heard anything about why overloading the existing interfaces, which leads to confusion, are required for this project. In other words, I haven't heard why we can not have separate interfaces which are similar to HV WDT design with corresponding MD fields to go along. That makes the interfaces cleaner and the functionality of the API is not dependent upon a MD property. Net-net, my previous questions are still unanswered. I understand that the project team's needs are met with what's proposed but those can also be met using separate interfaces which parallel current HV WDT interfaces. This gives us an option to extend these interfaces in future. If a meeting is needed to discuss my set of issues then lets do that. I am derailing this case for full meeting but I would like to discuss and get my issues addressed. Thanks. > With the HV WDT, Solaris specifies this value to the WDT. > With the Monza WDT, the value is 100mS - but is this hardwired into > Solaris? > If not, where is Solaris getting the value? > > What happens with the next HW WDT that has a period of 85mS? > I agree that this will meet the immediate needs, my concern is > not having to re-whack all this for the next HW WDT. > > jack -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Tue Feb 26 12:02:01 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QK21sU011838 for ; Tue, 26 Feb 2008 12:02:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QK1x5B038767; Tue, 26 Feb 2008 13:02:01 -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-3.04 (built Jul 15 2005)) id <0JWV00A133NCF200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 12:02:00 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00L9Y3LJRI80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 12:00:55 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QK0tLP021594; Tue, 26 Feb 2008 12:00:55 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWV006013I7O800@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Tue, 26 Feb 2008 12:00:55 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWV002LM3LIVC20@fe-sfbay-09.sun.com>; Tue, 26 Feb 2008 12:00:55 -0800 (PST) Date: Tue, 26 Feb 2008 12:00:54 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C467BB.50509@Sun.COM> Sender: Raghunath.Shenbagam@sun.com To: Hitendra Zhangada Cc: Jack.Bochsler@sun.com, Firmware Arch , atca-wdt-dev@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C46FF6.10903@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_YVubWGMyp6HUS47DKzAZkw)" X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> <47C4545D.9000806@Sun.COM> <47C456C4.70200@Sun.COM> <47C467BB.50509@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 6991 This is a multi-part message in MIME format. --Boundary_(ID_YVubWGMyp6HUS47DKzAZkw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hitendra Zhangada wrote: > Jack.Bochsler@Sun.COM wrote: >> Raghunath Shenbagam wrote the following on 02/26/08 10:03: >>> Jack.Bochsler@Sun.COM wrote: >>>> Regarding determination of the WDT period - is this still a >>>> requirement, >>>> that the HV provide the period to the Guest? >>>> >>>> I didn't see a response from the HW side - whether this can be done. >>> Sorry, though i addressed this qn.. >>> >>> WDT period set(or timeout left during "pat") is not a requirement >>> for this project. >>> >> But I believe the root problem is: >> How does Solaris know the correct WDT period? >> > > This is a good question to answer. I think this needs to be in MD > similar to the HV WDT design. > > I also believe we should have a way to stop and set time-out values. > As I said earlier if HW does not support this then it can be ignored > with an error status. > > As for what happens when control domain reboots/reset, I think > the behavior should be that these WDT be stopped and should > only be enabled when SW decides to do so upon reboot. Requiring > user to disable timers using UI is not good. What this means is that > if a system reboots, lets say PANIC reboot, when user is not around > then there is possibility of HW WDT trigger while in OpenBoot, > Solaris boot or in Solaris before Solaris starts patting the timer. > > Lastly, I still haven't heard anything about why overloading the > existing interfaces, which leads to confusion, are required for > this project. In other words, I haven't heard why we can not > have separate interfaces which are similar to HV WDT design > with corresponding MD fields to go along. That makes the > interfaces cleaner and the functionality of the API is not dependent > upon a MD property. > > Net-net, my previous questions are still unanswered. > > I understand that the project team's needs are met with what's > proposed but those can also be met using separate interfaces > which parallel current HV WDT interfaces. This gives us an option > to extend these interfaces in future. > > > If a meeting is needed to discuss my set of issues then lets do > that. I am derailing this case for full meeting but I would like > to discuss and get my issues addressed. Hitendra, I understand and agree to some of your argument. This project request changes(in terms of internal implementation) to existing hv wdt api. I do agree that we need to define a comprehensive hw wdt apis in hypervisor to setup/enable/pat/disable. But that is not a requirement for ATCA WDT project.The extensions to hv for hw wdt, that you are asking for, is outside the scope of this project. Now your qn. is down to: should this support be in the existing hv wdt api or define a new hv api, similar to hv wdt interface, to meet atca wdt requirement(i am open for either options). Greg Onufer in a previous e-mail(attached) had explained the reason for using current hv wdt api. I am more than happy to explain project requirement during a meeting, hv team can present the justification for using the hv wdt api during the same. Regards, Raghu --Boundary_(ID_YVubWGMyp6HUS47DKzAZkw) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from fe-sfbay-10.sun.com ([192.18.34.120]) by sfbay1-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JWU000FXECNRH20@sfbay1-mail1.sfbay.sun.com> for raghus@sfbay1-mail1.sfbay.Sun.COM; Tue, 26 Feb 2008 02:55:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWU00201EBWRV00@fe-sfbay-10.sun.com> for raghus@sfbay1-mail1.sfbay.Sun.COM (ORCPT raghus@sfbay1-mail1.sfbay.Sun.COM) ; Tue, 26 Feb 2008 02:55:35 -0800 (PST) Received: from phys-sfbay1-2.sfbay.sun.com ([129.145.47.13]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JWU00IMPECN0P30@fe-sfbay-10.sun.com> for raghus@sfbay1-mail1.sfbay.Sun.COM (ORCPT raghus@sfbay1-mail1.sfbay.Sun.COM) ; Tue, 26 Feb 2008 02:55:35 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by sfbay1-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JWU000FTECNRH20@sfbay1-mail1.sfbay.sun.com> for raghus@sfbay1-mail1.sfbay.Sun.COM; Tue, 26 Feb 2008 02:55:35 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1QAtZ7o005612; Tue, 26 Feb 2008 02:55:35 -0800 (PST) Received: from jazz.home (x-files.SFBay.Sun.COM [129.146.96.102]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1QAtYV2000787; Tue, 26 Feb 2008 02:55:34 -0800 (PST) Date: Tue, 26 Feb 2008 02:55:34 -0800 From: Greg Onufer Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C37274.2050104@sun.com> To: David Kahn Cc: Jack.Bochsler@Sun.COM, Raghunath.Shenbagam@Sun.COM Message-id: <86B7B0B1-8D22-4667-B1A8-EEFEAC88A732@Sun.COM> X-Envelope-from: Raghunath.Shenbagam@Sun.COM X-Envelope-to: atca-wdt-dev <@smarthost.sun.com:atca-wdt-dev@sun.com>, fwarc <@smarthost.sun.com:fwarc@sun.com> MIME-version: 1.0 (Apple Message framework v919.2) X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: <47BE088E.9090101@sun.com> <47BE0B73.5010501@sun.com> <47BE1184.10008@sun.com> <47BE271B.1090303@sun.com> <47BE322E.1020208@sun.com> <47BE38DF.80404@sun.com> <47C36424.1010002@Sun.COM> <47C36759.4070905@sun.com> <47C36913.5000808@sun.com> <47C37103.4040909@sun.com> <47C37274.2050104@sun.com> Original-recipient: rfc822;raghus@sfbay1-mail1.sfbay.Sun.COM On Feb 25, 2008, at 5:59 PM, David Kahn wrote: > We're overloading an interface to deal with a specific > instance of hardware, rather than creating an interface > for a generic hw wd timer. We have a generic wd timer interface, that's what was FWARC'd ages ago. I don't know where the overloading came from but it's clearly there in the proposed usage -- "one of two watchdog timers". It was just supposed to be /the/ watchdog on those platforms-- using the sun4v API to pat the watchdog which happens to, behind the scenes, pat the hardware watchdog. I'll agree with Hitendra on this one. And those properties /were/ in the guest MD-- alongside hostid, banner- name, etc., and with underscores instead of dashes. There is never a good reason for providing to the guest physical addresses which only the hypervisor should know about. Cheers!greg --Boundary_(ID_YVubWGMyp6HUS47DKzAZkw)-- From sacadmin Tue Feb 26 12:49:53 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QKnrR9013706 for ; Tue, 26 Feb 2008 12:49:53 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1QKnq4G018048; Tue, 26 Feb 2008 12:49:52 -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-3.04 (built Jul 15 2005)) id <0JWV00E0D5V4WT00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 12:49:52 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00LDU5V3S0D0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Feb 2008 12:49:51 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QKnpfB028784; Tue, 26 Feb 2008 12:49:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWV003015SK9600@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Tue, 26 Feb 2008 12:49:51 -0800 (PST) Received: from [129.153.85.8] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWV000YS5UYPM90@fe-sfbay-09.sun.com>; Tue, 26 Feb 2008 12:49:46 -0800 (PST) Date: Tue, 26 Feb 2008 12:49:42 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C467BB.50509@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Jack.Bochsler@sun.com, Firmware Arch Cc: Raghunath.Shenbagam@sun.com, atca-wdt-dev@sun.com Message-id: <47C47B66.9050309@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> <47C4545D.9000806@Sun.COM> <47C456C4.70200@Sun.COM> <47C467BB.50509@Sun.COM> User-Agent: Thunderbird 2.0.0.12pre (X11/20071231) Status: RO Content-Length: 4025 Hitendra Zhangada wrote: > Jack.Bochsler@Sun.COM wrote: >> >> >> Raghunath Shenbagam wrote the following on 02/26/08 10:03: >>> Jack.Bochsler@Sun.COM wrote: >>>> >>>> >>>> Jack.Bochsler@Sun.COM wrote the following on 02/25/08 17:32: >>>>> >>>>> >>>>> David Kahn wrote the following on 02/25/08 17:22: >>>>>> >>>>>> >>>>>> Jack.Bochsler@sun.com wrote: >>>>>> >>>>>>> This is the 3rd WDT that I have worked with - all have been fixed >>>>>>> period, but that may reflect more my limited experience than >>>>>>> reality. >>>>>> >>>>>> ok, so even if it's a fixed period, how is the generic >>>>>> software supposed to know what that fixed period is? >>>>>> >>>>>> With the overloaded interface, the timeout value isn't >>>>>> really used in the HW WD case, right? (It doesn't actually >>>>>> define a timeout value). >>>>>> >>>>> Note that at the moment, this is a secret value - HV doesn't >>>>> know the timeout either, it is purely in the hardware. >>>>> >>>>> There *could* be a property providing an address (and size) >>>>> for HV to read the timeout value, and pass this back to the >>>>> guest. Not sure if the HW guys are willing/able to do this. >>>>> >>>> Regarding determination of the WDT period - is this still a >>>> requirement, >>>> that the HV provide the period to the Guest? >>>> >>>> I didn't see a response from the HW side - whether this can be done. >>> Sorry, though i addressed this qn.. >>> >>> WDT period set(or timeout left during "pat") is not a requirement >>> for this project. >>> >> But I believe the root problem is: >> How does Solaris know the correct WDT period? >> > > This is a good question to answer. I think this needs to be in MD > similar to the HV WDT design. > > I also believe we should have a way to stop and set time-out values. > As I said earlier if HW does not support this then it can be ignored > with an error status. > > As for what happens when control domain reboots/reset, I think > the behavior should be that these WDT be stopped and should > only be enabled when SW decides to do so upon reboot. Requiring > user to disable timers using UI is not good. What this means is that > if a system reboots, lets say PANIC reboot, when user is not around > then there is possibility of HW WDT trigger while in OpenBoot, > Solaris boot or in Solaris before Solaris starts patting the timer. > > Lastly, I still haven't heard anything about why overloading the > existing interfaces, which leads to confusion, are required for > this project. In other words, I haven't heard why we can not > have separate interfaces which are similar to HV WDT design > with corresponding MD fields to go along. That makes the > interfaces cleaner and the functionality of the API is not dependent > upon a MD property. > > Net-net, my previous questions are still unanswered. > > I understand that the project team's needs are met with what's > proposed but those can also be met using separate interfaces > which parallel current HV WDT interfaces. This gives us an option > to extend these interfaces in future. > > > If a meeting is needed to discuss my set of issues then lets do > that. I am derailing this case for full meeting but I would like Typo, missed "not" above. I am NOT derailing this case but still would like to understand the design. Sorry about that. Thanks Sunit for catching it. > to discuss and get my issues addressed. > > > Thanks. >> With the HV WDT, Solaris specifies this value to the WDT. >> With the Monza WDT, the value is 100mS - but is this hardwired into >> Solaris? >> If not, where is Solaris getting the value? >> >> What happens with the next HW WDT that has a period of 85mS? >> I agree that this will meet the immediate needs, my concern is >> not having to re-whack all this for the next HW WDT. >> >> jack > > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu From sacadmin Tue Feb 26 13:20:33 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1QLKWHh014885 for ; Tue, 26 Feb 2008 13:20:33 -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 m1QLKOAT029494; Wed, 27 Feb 2008 05:20:32 +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 <0JWV00L037A4LF00@brm-avmta-1.central.sun.com>; Tue, 26 Feb 2008 14:20:28 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00HU57A24W30@brm-avmta-1.central.sun.com>; Tue, 26 Feb 2008 14:20:26 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1QLKQrx000704; Tue, 26 Feb 2008 13:20:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWV00L0174TPS00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Tue, 26 Feb 2008 13:20:26 -0800 (PST) Received: from [129.153.85.8] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWV000IZ79Z3EG0@fe-sfbay-10.sun.com>; Tue, 26 Feb 2008 13:20:23 -0800 (PST) Date: Tue, 26 Feb 2008 13:20:19 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47C46FF6.10903@Sun.COM> Sender: Hitendra.Zhangada@sun.com To: Raghunath.Shenbagam@sun.com Cc: Jack.Bochsler@sun.com, Firmware Arch , atca-wdt-dev@sun.com, Greg Onufer Message-id: <47C48293.6000005@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rPKhwqRpZIKyPQgj8CZFEQ)" X-PMX-Version: 5.2.0.264296 References: <47C369D1.3090305@sun.com> <47C36C46.9080207@Sun.COM> <47C45153.1080009@Sun.COM> <47C4545D.9000806@Sun.COM> <47C456C4.70200@Sun.COM> <47C467BB.50509@Sun.COM> <47C46FF6.10903@Sun.COM> User-Agent: Thunderbird 2.0.0.12pre (X11/20071231) Status: RO Content-Length: 16111 This is a multi-part message in MIME format. --Boundary_(ID_rPKhwqRpZIKyPQgj8CZFEQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Raghunath Shenbagam wrote: > Hitendra Zhangada wrote: >> Jack.Bochsler@Sun.COM wrote: >>> Raghunath Shenbagam wrote the following on 02/26/08 10:03: >>>> Jack.Bochsler@Sun.COM wrote: >>>>> Regarding determination of the WDT period - is this still a >>>>> requirement, >>>>> that the HV provide the period to the Guest? >>>>> >>>>> I didn't see a response from the HW side - whether this can be done. >>>> Sorry, though i addressed this qn.. >>>> >>>> WDT period set(or timeout left during "pat") is not a requirement >>>> for this project. >>>> >>> But I believe the root problem is: >>> How does Solaris know the correct WDT period? >>> >> >> This is a good question to answer. I think this needs to be in MD >> similar to the HV WDT design. >> >> I also believe we should have a way to stop and set time-out values. >> As I said earlier if HW does not support this then it can be ignored >> with an error status. >> >> As for what happens when control domain reboots/reset, I think >> the behavior should be that these WDT be stopped and should >> only be enabled when SW decides to do so upon reboot. Requiring >> user to disable timers using UI is not good. What this means is that >> if a system reboots, lets say PANIC reboot, when user is not around >> then there is possibility of HW WDT trigger while in OpenBoot, >> Solaris boot or in Solaris before Solaris starts patting the timer. >> >> Lastly, I still haven't heard anything about why overloading the >> existing interfaces, which leads to confusion, are required for >> this project. In other words, I haven't heard why we can not >> have separate interfaces which are similar to HV WDT design >> with corresponding MD fields to go along. That makes the >> interfaces cleaner and the functionality of the API is not dependent >> upon a MD property. >> >> Net-net, my previous questions are still unanswered. >> >> I understand that the project team's needs are met with what's >> proposed but those can also be met using separate interfaces >> which parallel current HV WDT interfaces. This gives us an option >> to extend these interfaces in future. >> >> >> If a meeting is needed to discuss my set of issues then lets do >> that. I am derailing this case for full meeting but I would like >> to discuss and get my issues addressed. > Hitendra, > I understand and agree to some of your argument. > > This project request changes(in terms of internal implementation) to > existing hv wdt api. I do agree that we need to define a comprehensive > hw wdt apis in hypervisor to setup/enable/pat/disable. But that is not a > requirement for ATCA WDT project.The extensions to hv for hw wdt, > that you are asking for, is outside the scope of this project. I understand that it is outside the scope but that does not mean we let this interface approved as is. I am not agreeing to what is proposed here. > > Now your qn. is down to: should this support be in the existing hv wdt > api or define a new hv api, similar to hv wdt interface, to meet atca > wdt > requirement(i am open for either options). Greg Onufer in a previous > e-mail(attached) had explained the reason for using current hv wdt api. See my comments to Greg's mail below. I was not on the Greg's mail thread. > > I am more than happy to explain project requirement during a > meeting, hv team can present the justification for using the hv wdt api > during the same. No one from HV team has spoken other than responses from Jack which seems to be agreeing to general comments I have. > > Regards, > Raghu > > > > > > ------------------------------------------------------------------------ > > Subject: > Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware > Watchdog timer > From: > Greg Onufer > Date: > Tue, 26 Feb 2008 02:55:34 -0800 > To: > David Kahn > > To: > David Kahn > CC: > Jack.Bochsler@Sun.COM, Raghunath.Shenbagam@Sun.COM > > > On Feb 25, 2008, at 5:59 PM, David Kahn wrote: >> We're overloading an interface to deal with a specific >> instance of hardware, rather than creating an interface >> for a generic hw wd timer. > > We have a generic wd timer interface, that's what was FWARC'd ages ago. Not sure what Greg means here. The original case defined by, http://sac.eng/Archives/CaseLog/arc/FWARC/2006/093/materials/ The case material clearly outlines how the interface needs to behave. I don't have problem with it. Similar interface for HW WDT is what I am suggesting for this case. > > I don't know where the overloading came from but it's clearly there in > the proposed usage -- "one of two watchdog timers". It was just > supposed to be /the/ watchdog on those platforms-- using the sun4v API > to pat the watchdog which happens to, behind the scenes, pat the > hardware watchdog. I'll agree with Hitendra on this one. > I don't have problem if the same/existing interfaces are used to use HW WDT instead of HV WDT on this platform. That information can be hidden inside of HV which is close to HW/platform. The issue I have is the overloading and different behavior between two. Further, no ability to disable it, set it etc. Use of MD property to toggle the behavior does not sound right either. Further as pointed out on FWARC mails, Solaris have no way of knowing what to expect with respect to the timer value. That should be communicated and Sun4v Solaris can decide based on that if it wants to enable it or not. > And those properties /were/ in the guest MD-- alongside hostid, > banner-name, etc., and with underscores instead of dashes. There is > never a good reason for providing to the guest physical addresses > which only the hypervisor should know about. Following properties were defined in the ARC case. watchdog-resolution Sun Private Machine Description platform node property watchdog-max-timeout Sun Private Machine Description platform node property Thanks. > > Cheers!greg > > > -- Hitendra Zhangada ==================================== SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Sun Ph# (858) 625 3757, Sun Ext. x53757 Internal homepage http://esp.west/~hitu --Boundary_(ID_rPKhwqRpZIKyPQgj8CZFEQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Raghunath Shenbagam wrote:
Hitendra Zhangada wrote:
Jack.Bochsler@Sun.COM wrote:
Raghunath Shenbagam wrote the following on 02/26/08 10:03:
Jack.Bochsler@Sun.COM wrote:
Regarding determination of the WDT period - is this still a requirement,
that the HV provide the period to the Guest?

I didn't see a response from the HW side - whether this can be done.
Sorry, though i addressed this qn..

WDT period set(or timeout left during "pat") is not a requirement for this project.

But I believe the root problem is:
    How does Solaris know the correct WDT period?


This is a good question to answer.  I think this needs to be in MD
similar to the HV WDT design.

I also believe we should have a way to stop and set time-out values.
As I said earlier if HW does not support this then it can be ignored
with an error status.

As for what happens when control domain reboots/reset, I think
the behavior should be that these WDT be stopped and should
only be enabled when SW decides to do so upon reboot.  Requiring
user to disable timers using UI is not good.  What this means is that
if a system reboots, lets say PANIC reboot, when user is not around
then there is possibility of HW WDT trigger while in OpenBoot,
Solaris boot or in Solaris before Solaris starts patting the timer.

Lastly, I still haven't heard anything about  why overloading  the
existing interfaces, which leads to confusion, are required for
this project.  In other words, I haven't heard why we can not
have separate interfaces which are similar to HV WDT design
with corresponding MD fields to go along.  That makes the
interfaces cleaner and the functionality of the API is not dependent
upon a MD property.

Net-net, my previous questions are still unanswered.

I understand that the project team's needs are met with what's
proposed but those can also be met using separate interfaces
which parallel current HV WDT interfaces.  This gives us an option
to extend these interfaces in future.


If a meeting is needed to discuss my set of issues then lets do
that.  I am derailing this case for full meeting but I would like
to discuss and get my issues addressed.
Hitendra,
   I understand and agree to some of your argument.

This project request changes(in terms of internal implementation) to
existing hv wdt api. I do agree that we need to define a comprehensive
hw wdt apis in hypervisor to setup/enable/pat/disable. But that is not a
requirement for ATCA WDT project.The extensions to hv for hw wdt,
that you are asking for, is outside the scope of this project.

I understand that it is outside the scope but that does not mean
we let this interface approved as is.  I am not agreeing to what is
proposed here.

Now your qn. is down to: should this support be in the existing hv wdt
api or  define a new hv api, similar to hv wdt interface, to meet atca wdt
requirement(i am open for either options). Greg Onufer in a previous
e-mail(attached) had explained the reason for using current hv wdt api.

See my comments to Greg's mail below.  I was not on the Greg's mail thread.

I am more than happy to explain project requirement during a
meeting, hv team can present the justification for using the hv wdt api
during the same.
No one from HV team has spoken other than responses from Jack
which seems to be agreeing to general comments I have.


Regards,
Raghu






Subject:
Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer
From:
Greg Onufer <Greg.Onufer@Sun.COM>
Date:
Tue, 26 Feb 2008 02:55:34 -0800
To:
David Kahn <David.Kahn@Sun.COM>
To:
David Kahn <David.Kahn@Sun.COM>
CC:
Jack.Bochsler@Sun.COM, Raghunath.Shenbagam@Sun.COM

On Feb 25, 2008, at 5:59 PM, David Kahn wrote:
We're overloading an interface to deal with a specific
instance of hardware, rather than creating an interface
for a generic hw wd timer.

We have a generic wd timer interface, that's what was FWARC'd ages ago.

Not sure what Greg means here.  The original case defined by,
http://sac.eng/Archives/CaseLog/arc/FWARC/2006/093/materials/

The case material clearly outlines how the interface needs to
behave.  I don't have problem with it.  Similar interface for
HW WDT is what I am suggesting for this case.

I don't know where the overloading came from but it's clearly there in the proposed usage -- "one of two watchdog timers". It was just supposed to be /the/ watchdog on those platforms-- using the sun4v API to pat the watchdog which happens to, behind the scenes, pat the hardware watchdog.  I'll agree with Hitendra on this one.


I don't have problem if the same/existing interfaces are used to use
HW WDT instead of HV WDT on this platform.  That information
can be hidden inside of HV which is close to HW/platform.  The issue
I have is the overloading and different behavior between two.  Further,
no ability to disable it, set it etc.  Use of MD property to toggle the
behavior does not sound right either.  Further as pointed out on FWARC
mails, Solaris have no way of knowing what to expect with respect to
the timer value.  That should be communicated and Sun4v Solaris can
decide based on that if it wants to enable it or not.
And those properties /were/ in the guest MD-- alongside hostid, banner-name, etc., and with underscores instead of dashes.   There is never a good reason for providing to the guest physical addresses which only the hypervisor should know about.

Following properties were defined in the ARC case.

watchdog-resolution		Sun Private	Machine Description platform
						node property

watchdog-max-timeout		Sun Private	Machine Description platform
						node property


Thanks.

Cheers!greg 





-- 
Hitendra Zhangada
====================================
SPS Common SW Features Engineering
Software Group, Sun Microsystems, Inc.
Sun Ph# (858) 625 3757, Sun Ext. x53757
Internal homepage http://esp.west/~hitu
--Boundary_(ID_rPKhwqRpZIKyPQgj8CZFEQ)-- From sacadmin Wed Feb 27 09:28:17 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RHSG1T019299 for ; Wed, 27 Feb 2008 09:28:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RHSDFQ025734 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 27 Feb 2008 17:28:15 GMT 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 <0JWW0021XR73JA00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 27 Feb 2008 10:28:15 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00M81R72QG30@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 27 Feb 2008 10:28:14 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1RHSDwi013409 for ; Wed, 27 Feb 2008 17:28:14 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWW00I01NYYYN00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 27 Feb 2008 10:28:13 -0700 (MST) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWW00DOJR6IHR30@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Wed, 27 Feb 2008 10:27:54 -0700 (MST) Date: Wed, 27 Feb 2008 09:27:54 -0800 From: Eduardo E Horvath Subject: [Fwd: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer] Sender: Eduardo.Horvath@sun.com To: Firmware Arch Message-id: <47C59D9A.6050601@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.13pre (X11/20080218) Status: RO Content-Length: 3716 If you don't want to know the gory details about this just hit delete. Montoya and Monza have 2 service processors, ILOM or ALOM, and an H8 microcontroller that's the IPMI controller for the board. The communication channel to the IPMC is a serial line connected to the PPC. This channel is dedicated for use by the control domain. When the control domain comes up, a service or LDC channel is established between the guest and the service processor. This channel is wired directly to the serial port driver on the LOM. Packets sent to the LDC are forwarded directly to the IPMC, and responses are sent back directly, with no processing done in the LOM. ILOM has its own IPMI controller code, but on Netra platforms the LOM does not supposed to exist, so it's completely ignored. The IPMI watchdog is defined by the IPMI standard. There are standard IPMI packets to configure, pat, and disable the watchdog. However, because of the latency of sending packets from the control domain, through the LDC channel to the SP, and then across an RS232 channel to the H8, and more importantly a misfeature of the design of the firmware running on the H8 that does not allow it to handle a watchdog pat packet while it's busy processing another longer latency packet, another non-standard method for patting the watchdog was developed involving a register in the FPGA driving an GPIO pin on the H8. The older SMC controller firmware design was able to immediately handle watchdog pat packets and therefore did not need to have to use a separate interrupt pin to pat the watchdog. Eduardo David Kahn wrote: > > > Jack.Bochsler@Sun.COM wrote: >> >> >> David Kahn wrote the following on 02/25/08 17:22: >>> >>> >>> Jack.Bochsler@sun.com wrote: >>> >>>> This is the 3rd WDT that I have worked with - all have been fixed >>>> period, but that may reflect more my limited experience than reality. >>> >>> ok, so even if it's a fixed period, how is the generic >>> software supposed to know what that fixed period is? >>> >>> With the overloaded interface, the timeout value isn't >>> really used in the HW WD case, right? (It doesn't actually >>> define a timeout value). >>> >> Note that at the moment, this is a secret value - HV doesn't >> know the timeout either, it is purely in the hardware. >> >> There *could* be a property providing an address (and size) >> for HV to read the timeout value, and pass this back to the >> guest. Not sure if the HW guys are willing/able to do this. >> >> This does beg the question though - what if the Guest can't >> support the heartbeat frequency (too fast)? So this means the query >> and enable are separate, and the guest shouldn't enable the >> HW WDT IFF it can't support it. >> >> But how does the guest know what it can support? Do we define yet >> another property to tell the guest? > > I think at some point, it's ok to assume that any given > hw wd has been designed so that it can actually be functional, > so while I think it's necessary for a generic guest to be > able to figure out what the trigger period is, we can leave > it as an exercise to application programming to figure out > how to make sure that it actually calls the API within the > correct period. (You could also go further with this. > For example, how do you take into account the overhead > of all the software in between the application and the > hardware?) > > For everything else you've said, I believe a separate > set of interfaces in their own API group would be much > better for the HW WD. One interface to get the period, > another (set of) interface(s) to enable/pat/disable the > hw watchdog timer. > > -David > > -- Eduardo Horvath -- Eduardo Horvath From sacadmin Wed Feb 27 15:48:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RNmljr010109 for ; Wed, 27 Feb 2008 15:48:47 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RNmjWx022384; Wed, 27 Feb 2008 16:48:47 -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-3.04 (built Jul 15 2005)) id <0JWX00L0N8TAWV00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 15:48:46 -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-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00JYQ8TA4T90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 15:48:46 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1RNmjBf000183; Wed, 27 Feb 2008 23:48:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX000018NJZP00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) ; Wed, 27 Feb 2008 16:48:45 -0700 (MST) Received: from [129.150.22.16] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00G468T81DB0@mail-amer.sun.com>; Wed, 27 Feb 2008 16:48:45 -0700 (MST) Date: Wed, 27 Feb 2008 15:48:42 -0800 From: Sunit Jain Subject: FWARC/2008/134 - revised material Sender: S.Jain@sun.com To: Firmware Arch Cc: atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Reply-to: S.Jain@sun.com Message-id: <47C5F6DA.8010104@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UXpgKmSsc4XYG3k3KPEOUA)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.12pre (Windows/20080123) Status: RO Content-Length: 3488 This is a multi-part message in MIME format. --Boundary_(ID_UXpgKmSsc4XYG3k3KPEOUA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT The project team (Raghu and Jack) met offline with Hitendra and me to discuss the issues raised for this case. The discussions has resulted into more cleaner solution than what was initially proposed for this case. The proposed changes are minimized to just additional return values to the current approved API. The proposal is to use the same API, as originally approved, no changes to how API works and what is expected from it. Only changes are in the return values. The changes are to return -1 if "time_remaining" is not available and to return ENOTSUPPORTED if timer can not be disabled. The changes are highlighted in the spec in the materials directory. Hypervisor takes care of the details on which of the two watchdog timers are used. On platforms with Hardware watchdog, Hypervisor can use this watchdog timer instead of the software (HV) timer. The decision on which timer to use is platform specific. For virtualized guest domains, the Hardware watchdog will not be available and hence Hypervisor will only support Software timers for virtual guest domains. Update spec and interface table are copied in case material directory: http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/ Since changes are small, I would like to extend timer for this case to 3 more days, until Monday March 3, 2008. Regards, Sunit --Boundary_(ID_UXpgKmSsc4XYG3k3KPEOUA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT The project team (Raghu and Jack) met offline with Hitendra and me
to discuss the issues raised for this case.  The discussions has resulted
into more cleaner solution than what was initially proposed for this case.
The proposed changes are minimized to just additional return values
to the current approved API.

The proposal is to use the same API, as originally approved, no changes to how
API works and what is expected from it.  Only changes are in the return values.
The changes are to return -1 if "time_remaining" is not available and to return
ENOTSUPPORTED  if timer can not be disabled. The changes are highlighted in
the spec in the materials directory.

Hypervisor takes care of the details on which of the two watchdog timers
are used.  On platforms with Hardware watchdog, Hypervisor can use this
watchdog timer instead of the software (HV) timer.  The decision on
which timer to use is platform specific.  For virtualized guest domains,
the Hardware watchdog will not be available and hence Hypervisor will
only support Software timers for virtual guest domains.

Update spec and interface table are copied in case material directory:
    http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/

Since changes are small, I would like to extend timer for this case
to 3 more days, until Monday March 3, 2008.

Regards,
Sunit

 --Boundary_(ID_UXpgKmSsc4XYG3k3KPEOUA)-- From sacadmin Wed Feb 27 20:18:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S4IueH019636 for ; Wed, 27 Feb 2008 20:18:57 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1S4Is7Y010377; Thu, 28 Feb 2008 12:18:55 +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-3.04 (built Jul 15 2005)) id <0JWX00507LBHMP00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 20:18:53 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX001SNLBHN0A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 20:18:53 -0800 (PST) Received: from dtmail.sfbay.sun.com (dt101-150.SFBay.Sun.COM [10.6.101.150]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1S4IqaK012459; Wed, 27 Feb 2008 20:18:52 -0800 (PST) Received: from [127.0.0.1] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1S4IoaH010493; Wed, 27 Feb 2008 20:18:51 -0800 (PST) Date: Wed, 27 Feb 2008 20:18:49 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - revised material To: Sunit Jain Cc: Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Message-id: <47C63629.4010800@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 1239 After talking to Greg today, I think the project team should just define a separate API and API group for the ACTA HW Watchdog Pat function. This is kind of a hack to work around the problems of using the ipmi micro controller directly, so we don't think this is a generally applicable hw wd interface, but we need to provide something for ACTA platforms to be able to pat the hw wd so it works. I'd rather just keep this interface in a separate API group, and not overload the existing HV WD API. There apparently was some confusion about the HV group's recomendation. It was supposed to be either HV WD *or* HW WD, but not both at the same time. Since it's a special platform-group or type specific API (specifically, it's for ACTA platforms with hw wd, that have a specific instance of an IPMI micro-controller that exhibits a specific problem when using IPMI from the host to the micro-controller to pat the hw wd) so there's no need to try to make it general purpose. The IPMI method is the general purpose method, and that method, for whatever reason, doesn't work. The best solution would be to try to make the IPMI method work, but I'm assuming that the project team has explored that and a solution doesn't exist. -David From sacadmin Wed Feb 27 20:42:15 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S4gFFG019802 for ; Wed, 27 Feb 2008 20:42:15 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1S4gE54019022; Wed, 27 Feb 2008 20:42:15 -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-3.04 (built Jul 15 2005)) id <0JWX0080BMEEAX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 20:42:14 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX007GKMEDFA20@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 20:42:14 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1S4gDqL007621; Wed, 27 Feb 2008 20:42:13 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX00201MAYYL00@fe-sfbay-10.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Wed, 27 Feb 2008 20:42:13 -0800 (PST) Received: from [129.150.32.12] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00J0VMECW030@fe-sfbay-10.sun.com>; Wed, 27 Feb 2008 20:42:13 -0800 (PST) Date: Wed, 27 Feb 2008 20:44:04 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C63629.4010800@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware Arch Cc: atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Message-id: <47C63C14.9060607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C63629.4010800@sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 2380 David Kahn wrote: > > After talking to Greg today, I think the > project team should just define a separate > API and API group for the ACTA HW Watchdog > Pat function. > > This is kind of a hack to work around the > problems of using the ipmi micro controller > directly, so we don't think this is a generally > applicable hw wd interface, but we need to > provide something for ACTA platforms to be > able to pat the hw wd so it works. IMO, the latest changes at an interface/API level are not hack. HW watchdog can act similar to how HV watchdog works. That's the point of the revised document. The API can work for ATCA or any other HW WDT support on other platforms. > > I'd rather just keep this interface in a > separate API group, and not overload the > existing HV WD API. That's fine but I want to point out that project team does want HV WDT for virtual domains and want HW WDT for control domain using the SAME APIs (same application runs on virtual domain also). So, instead of inventing new ones to do both, why not use the one that is already been defined with a minimal changes to the return values. Actually, ATCA does not even care for that, it was added to support HW WDT in a proper way. > > There apparently was some confusion about the > HV group's recomendation. It was supposed to > be either HV WD *or* HW WD, but not both > at the same time. The latest proposal is to do that only, "or" not both. Platform decide if it wants to use HW or HV for control domain and for guest domains it is always HV. > > Since it's a special platform-group or type > specific API (specifically, it's for ACTA > platforms with hw wd, that have a specific > instance of an IPMI micro-controller that > exhibits a specific problem when using IPMI > from the host to the micro-controller to pat > the hw wd) so there's no need to try to make > it general purpose. The IPMI method is the > general purpose method, and that method, > for whatever reason, doesn't work. > > The best solution would be to try to make > the IPMI method work, but I'm assuming that > the project team has explored that and a solution > doesn't exist. > > > -David > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Wed Feb 27 21:13:10 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S5D9M2020236 for ; Wed, 27 Feb 2008 21:13:09 -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 m1S5D6b6001032; Thu, 28 Feb 2008 13:13:08 +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 <0JWX00C05NTVOS00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 22:13:07 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX007SANTT9N20@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 22:13:06 -0700 (MST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1S5D5Bs037275; Wed, 27 Feb 2008 21:13:05 -0800 (PST) Received: from [127.0.0.1] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1S5D3nu010838; Wed, 27 Feb 2008 21:13:04 -0800 (PST) Date: Wed, 27 Feb 2008 21:13:03 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - revised material To: Hitendra Zhangada Cc: Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Message-id: <47C642DF.3030000@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 1560 Hitendra Zhangada wrote: > That's fine but I want to point out that project team > does want HV WDT for virtual domains and want > HW WDT for control domain using the SAME > APIs (same application runs on virtual domain also). > So, instead of inventing new ones to do both, Creating a new API group for the ACTA hw wd does not prevent the guests (priv or not) from using the existing HV API in addition to or in lieu of the new API in the control domain. Non-priv-ed guests can continue to use the existing HV WD API. ... > The latest proposal is to do that only, "or" not both. ok, which is it? Either one or the other or both? I'm confused by those two statements. A single API that has two distinct functions depending on the arguments and if the guest is privileged or not seems like it's doing both. I don't know how else to look at it, because that's what the code will have to do. I read about the changes, and the changes were minimal and still do both. The correct way to do the ACTA timer support is via IMPI. For various reasons it doesn't work, and I'm not convinced that overloading the HV WD with a second interface capable of running simultaneously as the original function is the best thing we could do here? Why does it hurt to create a new API for this thing? It's trivial to do that, except it creates a new API group and a new API in that group. > Platform decide if it wants to use HW or HV for > control domain and for guest domains it is always HV. Using a single overloaded API, right? Or did I miss something? -David From sacadmin Wed Feb 27 22:04:36 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S64ZS6020860 for ; Wed, 27 Feb 2008 22:04:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1S64XxQ020172; Thu, 28 Feb 2008 14:04:34 +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-3.04 (built Jul 15 2005)) id <0JWX00H03Q7LG800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 22:04:33 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00CE3Q7KSHC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 27 Feb 2008 22:04:32 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1S64WRc009647; Wed, 27 Feb 2008 22:04:32 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX00J01Q5YK800@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM); Wed, 27 Feb 2008 22:04:32 -0800 (PST) Received: from [192.168.2.3] ([71.136.73.128]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX0003GQ7JYV80@fe-sfbay-09.sun.com>; Wed, 27 Feb 2008 22:04:32 -0800 (PST) Date: Wed, 27 Feb 2008 22:06:23 -0800 From: Hitendra Zhangada Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C642DF.3030000@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware Arch Cc: atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Message-id: <47C64F5F.8070706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C642DF.3030000@sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 4105 David Kahn wrote: > > > Hitendra Zhangada wrote: > >> That's fine but I want to point out that project team >> does want HV WDT for virtual domains and want >> HW WDT for control domain using the SAME >> APIs (same application runs on virtual domain also). >> So, instead of inventing new ones to do both, > I would do like to clarify some of the questions in this mail. > Creating a new API group for the ACTA hw wd does not > prevent the guests (priv or not) from using the existing > HV API in addition to or in lieu of the new API in the > control domain. Non-priv-ed guests can continue to > use the existing HV WD API. Yeah, but their application wants to use the same for both control and guest domains. I don't think it makes sense for application/daemon to check if it is control domain or guest domain and then use different set of APIs. > > > ... > > >> The latest proposal is to do that only, "or" not both. > > ok, which is it? Either one or the other or both? What I meant was that API will either support HV WDT or HV WDT for a guest/domain, not both at the HV level. The original proposal was to support both based on some values in the MD. Platform can determine what underline mechanism they want to use for a control domain. HV will then use one of the two mechanisms, and the mechanism itself is not exposed to sun4v guests. > I'm confused by those two statements. A single API > that has two distinct functions depending on the > arguments and if the guest is privileged or not > seems like it's doing both. I don't know how else No API has one function as specified by the API. It is to set timeout, enable/disable timers etc. A sun4v guest should not care if it is done through HV or using a HW. This way API is more generic for sun4v guests. > to look at it, because that's what the code will > have to do. Difference between use of HW vs HV is all the implementation details in HV which itself is tied to HW/platform. By design, HV should isolate HW details from sun4v guest. > > I read about the changes, and the changes were minimal > and still do both. > > The correct way to do the ACTA timer support is via > IMPI. For various reasons it doesn't work, and I'm not > convinced that overloading the HV WD with a second > interface capable of running simultaneously as the > original function is the best thing we could do here? Just want to clarify that the current APIs does not state anything about use of HV WDT. It is just there for watchdog support. The implementation we have today is implemented in HV but that does not mean APIs are designed for HV WDT only. > > Why does it hurt to create a new API for this thing? > It's trivial to do that, except it creates a new > API group and a new API in that group. > A problem I can think of is that the new APIs may not look like sun4v neutral or it will look just like the existing API since it has to work in both control and guest domains with two different WDT (HW for control domain and HV for guest domains). Other than above I am fine with it. >> Platform decide if it wants to use HW or HV for >> control domain and for guest domains it is always HV. > > Using a single overloaded API, right? Or did I miss > something? Overloading, if you call it as such, happens at the HV layer. From sun4v guest point of view, it is enabling/disabling/patting a watchdog. I am coming from sun4v guest point of view which is what consumes the API. They don't see or should even be aware of different mechanisms at HV layer. That said, do you mind suggesting an API for this project which utilizes HW WDT for control domain and HV WDT for guest domain. I am not sure if you got this detail straight or not but as per Raghu they have same application running on both control and virtual domains, the application/daemon would like to use the same APIs in both. Thanks. > > -David > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Wed Feb 27 23:08:24 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1S78OK5023012 for ; Wed, 27 Feb 2008 23:08:24 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1S78Nhu046716; Thu, 28 Feb 2008 00:08:24 -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 <0JWX00307T5ZRH00@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 23:08:23 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX003CPT5ZC800@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 23:08:23 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1S78NhW029372; Wed, 27 Feb 2008 23:08:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX00301T3FA200@fe-sfbay-09.sun.com> (original mail from Jack.Bochsler@Sun.COM); Wed, 27 Feb 2008 23:08:23 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00GYBT5Z4M30@fe-sfbay-09.sun.com>; Wed, 27 Feb 2008 23:08:23 -0800 (PST) Date: Wed, 27 Feb 2008 23:08:19 -0800 From: Jack.Bochsler@sun.com Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C64F5F.8070706@sun.com> Sender: Jack.Bochsler@sun.com To: Hitendra Zhangada Cc: Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam Message-id: <47C65DE3.1000004@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms050206090508060707030402; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47C642DF.3030000@sun.com> <47C64F5F.8070706@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 5721 --------------ms050206090508060707030402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hitendra Zhangada wrote the following on 02/27/08 22:06: [text elided] > > That said, do you mind suggesting an API for this project > which utilizes HW WDT for control domain and HV WDT > for guest domain. I am not sure if you got this detail straight > or not but as per Raghu they have same application running > on both control and virtual domains, the application/daemon > would like to use the same APIs in both. > > I am interesting in what you are thinking here as well. If I had to define a HW WDT API today - it would look just like the existing one. Having two interfaces would end up pushing the selection of implementation to the consumer. Does a consumer really care about the implementation HW vs SW - or just getting the service? So it isn't clear to me what defining a new interface would achieve. jack --------------ms050206090508060707030402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyODA3MDgxOVowIwYJKoZIhvcNAQkEMRYEFFcy gm3qFqcvQ31gikvz2Bsx9dbiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQCktV/3Pa+DsOdTECwTcS5XUqOw/99rixq19Wx29WBs0qlMD+B7 pSZISh69oUsNMEks5XztWht71FXxRLaydnLsbaF43RDSqIzHo8uZxRe1JeucUjt3UYpbyRHD DGbfT2lHOoU6BDOeFBMcktEGKP2uW+EPROlgETBSsWA4+TEorwEScOITjeAgZtYO3e+xwT4x s1G3iIJL1lu7MTTdhBnmLSsbwkZZiJ9P/kpjzOddusz0qKcpQLGHCylkYcx4fHsK9vt4sqX1 sHmWHI5RcC72Hc9zpddLeIetEEiPxZR2/5tTZw6HxhPTswY2BZJDjHO/oQzClq8LKwdN+D5E EDZwAAAAAAAA --------------ms050206090508060707030402-- From sacadmin Thu Feb 28 02:05:51 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SA5p5F027039 for ; Thu, 28 Feb 2008 02:05:51 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SA5os2008089; Thu, 28 Feb 2008 02:05:51 -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-3.04 (built Jul 15 2005)) id <0JWY00K0J1DQVV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 28 Feb 2008 02:05:50 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00IMY1DPO7E0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 28 Feb 2008 02:05:49 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1SA5nIc018879; Thu, 28 Feb 2008 02:05:49 -0800 (PST) Received: from [127.0.0.1] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1SA5lnZ011957; Thu, 28 Feb 2008 02:05:47 -0800 (PST) Date: Thu, 28 Feb 2008 02:05:47 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - revised material To: Hitendra Zhangada Cc: Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Message-id: <47C6877B.3080201@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 874 Hitendra Zhangada wrote: > Yeah, but their application wants to use the same for both > control and guest domains. I don't think it makes sense > for application/daemon to check if it is control domain > or guest domain and then use different set of APIs. I'm assuming that the application does know because the application that pats the HW WD should be doing it by IPMI (and attempted to do it via IPMI, but had problems with that method) so it switched over to this new interface, which was created to bypass the microcontroller problems. If it wasn't for that problem, they would be using IMPI only to interact with the ATCA HW WD. At least that's how it was explained to me. This is the first time I heard that they are using the same application to pat the hw wd. I don't really care about this that much to derail the case, so I'm not going to do that. -David From sacadmin Thu Feb 28 08:30:44 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SGUiQS007695 for ; Thu, 28 Feb 2008 08:30:44 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SGUd3b020268; Thu, 28 Feb 2008 08:30:44 -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 <0JWY00K19J769C00@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 09:30:42 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00IJ0J6TRN10@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 09:30:30 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1SGUTqd010900; Thu, 28 Feb 2008 16:30:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWY00K01II1IS00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM); Thu, 28 Feb 2008 09:30:29 -0700 (MST) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWY004THJ6RYH00@mail-amer.sun.com>; Thu, 28 Feb 2008 09:30:28 -0700 (MST) Date: Thu, 28 Feb 2008 08:30:27 -0800 From: Eduardo E Horvath Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6877B.3080201@sun.com> Sender: Eduardo.Horvath@sun.com To: David Kahn Cc: Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam , Jack.Bochsler@sun.com Message-id: <47C6E1A3.2060207@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> User-Agent: Thunderbird 2.0.0.13pre (X11/20080218) Status: RO Content-Length: 1427 David Kahn wrote: > > > Hitendra Zhangada wrote: > >> Yeah, but their application wants to use the same for both >> control and guest domains. I don't think it makes sense >> for application/daemon to check if it is control domain >> or guest domain and then use different set of APIs. > > I'm assuming that the application does know because > the application that pats the HW WD should be doing > it by IPMI (and attempted to do it via IPMI, but had > problems with that method) so it switched over to > this new interface, which was created to bypass the > microcontroller problems. If it wasn't for that > problem, they would be using IMPI only to interact > with the ATCA HW WD. At least that's how it was > explained to me. > > This is the first time I heard that they are using > the same application to pat the hw wd. > > I don't really care about this that much to derail > the case, so I'm not going to do that. Unless I'm missing something, this case only covers the patting of the ATCA watchdog, but does not give information about what is involved in setting the timeout, starting it, or stopping it. I don't really thing you should let this case be approved without such information in the case material. If anyone else tries to use this feature he should not find the need to add some secret magic sauce that's not documented or at least explicitly referred to in this case. -- Eduardo Horvath From sacadmin Thu Feb 28 08:32:48 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SGWlr7007727 for ; Thu, 28 Feb 2008 08:32:48 -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 m1SGWku3025247; Fri, 29 Feb 2008 00:32:46 +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 <0JWY00KBDJAK6900@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 09:32:44 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY00I2SJAIR720@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 09:32:42 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1SGWgJv020009; Thu, 28 Feb 2008 08:32:42 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWY00K01J4S5900@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 28 Feb 2008 08:32:42 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWY003KCJA9FW80@fe-sfbay-09.sun.com>; Thu, 28 Feb 2008 08:32:34 -0800 (PST) Date: Thu, 28 Feb 2008 08:32:33 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6877B.3080201@sun.com> Sender: Raghunath.Shenbagam@sun.com To: David Kahn Cc: Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Jack.Bochsler@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C6E221.1050100@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1663 David Kahn wrote: > Hitendra Zhangada wrote: >> Yeah, but their application wants to use the same for both >> control and guest domains. I don't think it makes sense >> for application/daemon to check if it is control domain >> or guest domain and then use different set of APIs. This is one of the goal for this project, we don't want to ask the customer to change their application(in user land) that pat watchdog timer. However, to accomodate LDOMs we may have a s/w in the kernel that filter the IPMI cmds before sending it down to the module that interface with hv. > I'm assuming that the application does know because > the application that pats the HW WD should be doing > it by IPMI (and attempted to do it via IPMI, but had > problems with that method) so it switched over to > this new interface, which was created to bypass the > microcontroller problems. If it wasn't for that Actually, we are creating a "shortcut" to IPMC. IPMC can accept wdt patting from either IPMI msg or in an intr. hdlr. IPMC provide a mechanism(intr pin) so the payload(host) can trigger an interrupt instead of a lengthy IPMI msg path. > problem, they would be using IMPI only to interact > with the ATCA HW WD. At least that's how it was > explained to me. > > This is the first time I heard that they are using > the same application to pat the hw wd. > > I don't really care about this that much to derail > the case, so I'm not going to do that. Since we still have two lines of thought, one using the same hv wdt api vs. defining a new api class that's fn. specific, i'd like to take is back to the A-team(project team) and have this discuss further. Thanks, Raghu From sacadmin Thu Feb 28 08:36:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SGaIXC007788 for ; Thu, 28 Feb 2008 08:36:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SGaGvW022246; Thu, 28 Feb 2008 08:36:18 -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 <0JWY0040ZJGHNO00@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 08:36:17 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY0018DJGFZQ60@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 08:36:16 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1SGaFKk020464; Thu, 28 Feb 2008 08:36:15 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWY00L01J0R4Y00@fe-sfbay-10.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Thu, 28 Feb 2008 08:36:15 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWY00J7KJFY5IF0@fe-sfbay-10.sun.com>; Thu, 28 Feb 2008 08:35:59 -0800 (PST) Date: Thu, 28 Feb 2008 08:35:58 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6E1A3.2060207@sun.com> Sender: Raghunath.Shenbagam@sun.com To: Eduardo E Horvath Cc: David Kahn , Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Jack.Bochsler@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C6E2EE.1000204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> <47C6E1A3.2060207@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1733 Eduardo E Horvath wrote: > David Kahn wrote: >> >> >> Hitendra Zhangada wrote: >> >>> Yeah, but their application wants to use the same for both >>> control and guest domains. I don't think it makes sense >>> for application/daemon to check if it is control domain >>> or guest domain and then use different set of APIs. >> >> I'm assuming that the application does know because >> the application that pats the HW WD should be doing >> it by IPMI (and attempted to do it via IPMI, but had >> problems with that method) so it switched over to >> this new interface, which was created to bypass the >> microcontroller problems. If it wasn't for that >> problem, they would be using IMPI only to interact >> with the ATCA HW WD. At least that's how it was >> explained to me. >> >> This is the first time I heard that they are using >> the same application to pat the hw wd. >> >> I don't really care about this that much to derail >> the case, so I'm not going to do that. > > Unless I'm missing something, this case only covers the patting > of the ATCA watchdog, but does not give information about what > is involved in setting the timeout, starting it, or stopping it. > I don't really thing you should let this case be approved without > such information in the case material. If anyone else tries to > use this feature he should not find the need to add some secret > magic sauce that's not documented or at least explicitly referred > to in this case. Like described in the onepager, wdt setup/disable for atca wdt is outside the scope of this project. I agree that if we are defining a generic hw wdt api in hypervisor, it need to address wd setup and disable in a generic way(and that's what we were trying to do). /Raghu From sacadmin Thu Feb 28 08:41:04 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SGf4nW007802 for ; Thu, 28 Feb 2008 08:41:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SGf0Lb013581; Thu, 28 Feb 2008 09:41:04 -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 <0JWY0047BJOEQX00@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 08:41:02 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWY001J5JOCZH60@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 08:41:00 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1SGex7Q021085; Thu, 28 Feb 2008 08:40:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWY00C01JHSBP00@fe-sfbay-10.sun.com> (original mail from Jack.Bochsler@Sun.COM); Thu, 28 Feb 2008 08:40:59 -0800 (PST) Received: from [129.153.85.37] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWY00F29JOB8B10@fe-sfbay-10.sun.com>; Thu, 28 Feb 2008 08:40:59 -0800 (PST) Date: Thu, 28 Feb 2008 08:40:55 -0800 From: jack.bochsler@sun.com Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6E1A3.2060207@sun.com> Sender: jack.bochsler@sun.com To: Eduardo E Horvath Cc: David Kahn , Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam Message-id: <47C6E417.1020102@Sun.COM> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms010209090902090508020108; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> <47C6E1A3.2060207@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1.12pre) Gecko/20071231 SeaMonkey/1.1.8pre Status: RO Content-Length: 6846 --------------ms010209090902090508020108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Where does open(2) explain how NFS automounts a disk to fullfill the call? IMO this is implementation in underlying the API, as above. Initially there was a 1-1 mapping of the interface to an implementation and it just worked. Note that there is no documentation on the implementation (or limitations) of the current SW WDT. So why does a second implementation of near identical functionality get this new burden of detailing implementation? jack Eduardo E Horvath wrote the following on 02/28/08 08:30: > David Kahn wrote: >> >> >> Hitendra Zhangada wrote: >> >>> Yeah, but their application wants to use the same for both >>> control and guest domains. I don't think it makes sense >>> for application/daemon to check if it is control domain >>> or guest domain and then use different set of APIs. >> >> I'm assuming that the application does know because >> the application that pats the HW WD should be doing >> it by IPMI (and attempted to do it via IPMI, but had >> problems with that method) so it switched over to >> this new interface, which was created to bypass the >> microcontroller problems. If it wasn't for that >> problem, they would be using IMPI only to interact >> with the ATCA HW WD. At least that's how it was >> explained to me. >> >> This is the first time I heard that they are using >> the same application to pat the hw wd. >> >> I don't really care about this that much to derail >> the case, so I'm not going to do that. > > > Unless I'm missing something, this case only covers the patting > of the ATCA watchdog, but does not give information about what > is involved in setting the timeout, starting it, or stopping it. > I don't really thing you should let this case be approved without > such information in the case material. If anyone else tries to > use this feature he should not find the need to add some secret > magic sauce that's not documented or at least explicitly referred > to in this case. > > > --------------ms010209090902090508020108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJRTCC Av0wggJmoAMCAQICECQtvbO4NqPXYXrvMs0HJwkwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDQxMDIxMTgzMFoX DTA4MDQwOTIxMTgzMFowYDERMA8GA1UEBBMIQm9jaHNsZXIxDTALBgNVBCoTBEphY2sxFjAU BgNVBAMTDUphY2sgQm9jaHNsZXIxJDAiBgkqhkiG9w0BCQEWFUphY2suQm9jaHNsZXJAU3Vu LkNPTTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqmYT9CB/BfD/iKbWY1VPPi s3q2MAymbEmYjRkrAQmK5amwobTz7Efl+iJfm97LQJZXLubG2kPKDvi/fqTGKS98yrUVkEom Ax/cRGBVdga5Evb5LQyMlZyym1yN3ZsKe8Z8vKlJU2RJ8V0tvZjSNW5VpdJLPs3kHluns34x 5oXs2tXGjNo7wJmMJf7kSoYEc599Hh8YLixa21lZhou8d7v1jojHw9qeBVY+148Ydv+LlUAl GVZybgKnsOzwSngHKNqk92Xl80f+tbB8zq20PX0WXLerJDuhChfqmq6nLJ4rmwOeh7ZOLmH8 iuhUAnL0Dgdr0a+i0InYZd/NPoTMh78CAwEAAaMyMDAwIAYDVR0RBBkwF4EVSmFjay5Cb2No c2xlckBTdW4uQ09NMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAklpZgWdjlFSh NybYZ96lcO6KA6Bzzcp1bS/rI698nrlBtGC9LAm7btWT6q/eviFAgnF+vaIPocctt1jSW2ZY eVaZEGNyRRl4jTupJ2Qm7BTAOH584eyqOom0DAr1H0DgeMHUF4nDPxONr7Ds+fXMhsVj6aB3 /8h5WF6Pj+XLzkgwggL9MIICZqADAgECAhAkLb2zuDaj12F67zLNBycJMA0GCSqGSIb3DQEB BQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0w NzA0MTAyMTE4MzBaFw0wODA0MDkyMTE4MzBaMGAxETAPBgNVBAQTCEJvY2hzbGVyMQ0wCwYD VQQqEwRKYWNrMRYwFAYDVQQDEw1KYWNrIEJvY2hzbGVyMSQwIgYJKoZIhvcNAQkBFhVKYWNr LkJvY2hzbGVyQFN1bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC6pmE/ QgfwXw/4im1mNVTz4rN6tjAMpmxJmI0ZKwEJiuWpsKG08+xH5foiX5vey0CWVy7mxtpDyg74 v36kxikvfMq1FZBKJgMf3ERgVXYGuRL2+S0MjJWcsptcjd2bCnvGfLypSVNkSfFdLb2Y0jVu VaXSSz7N5B5bp7N+MeaF7NrVxozaO8CZjCX+5EqGBHOffR4fGC4sWttZWYaLvHe79Y6Ix8Pa ngVWPtePGHb/i5VAJRlWcm4Cp7Ds8Ep4ByjapPdl5fNH/rWwfM6ttD19Fly3qyQ7oQoX6pqu pyyeK5sDnoe2Ti5h/IroVAJy9A4Ha9GvotCJ2GXfzT6EzIe/AgMBAAGjMjAwMCAGA1UdEQQZ MBeBFUphY2suQm9jaHNsZXJAU3VuLkNPTTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAJJaWYFnY5RUoTcm2GfepXDuigOgc83KdW0v6yOvfJ65QbRgvSwJu27Vk+qv3r4hQIJx fr2iD6HHLbdY0ltmWHlWmRBjckUZeI07qSdkJuwUwDh+fOHsqjqJtAwK9R9A4HjB1BeJwz8T ja+w7Pn1zIbFY+mgd//IeVhej4/ly85IMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAkLb2zuDaj12F67zLNBycJMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIyODE2NDA1NVowIwYJKoZIhvcNAQkEMRYEFJWx lFs7VLkfh9FA2mUPAqoi9zI0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQJC29s7g2o9dheu8yzQcnCTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQJC29s7g2o9dheu8yzQcnCTAN BgkqhkiG9w0BAQEFAASCAQBa29jkfoFgZbEnzfPmHH8yBhX0e8S49b2EDyoqsarlUcfG40KG /hgCEVybSH88KOUdBKCGWXyRJQg1d5xaAfB7VfMtcz5fOU/Dt09cWEleEiF67bWsUklDVHH3 b84PAlES6XhzNQQIF1AGEF3eWLkQlXfa56CtHivn12z2BbDFqK0DIOFUDKiHdhfYVRv6FZbG +kVg8GmDe1Z0OXiSlaJO+LUc5HfVaC7PZBBCRlKZ01ZQrZiKAYL0Fc4Ga8h3a/EFQjbSe552 nxGVdv5fixFA5taETagAoPBZULodEvbBZk9SGU8rqovX0czSMTRIpd4j0cbD8X+HFCujDggY EBmtAAAAAAAA --------------ms010209090902090508020108-- From sacadmin Thu Feb 28 08:57:23 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1SGvMdF008213 for ; Thu, 28 Feb 2008 08:57:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1SGvGlK029243; Thu, 28 Feb 2008 08:57:21 -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 <0JWY0050DKFKDC00@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 08:57:20 -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 <0JWY001FZKFDZP70@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 08:57:13 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1SGvDhp023212; Thu, 28 Feb 2008 16:57:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWY00M01JZ3JR00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM); Thu, 28 Feb 2008 09:57:13 -0700 (MST) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWY00BZ6KF91C20@mail-amer.sun.com>; Thu, 28 Feb 2008 09:57:09 -0700 (MST) Date: Thu, 28 Feb 2008 08:57:09 -0800 From: Eduardo E Horvath Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6E417.1020102@Sun.COM> Sender: Eduardo.Horvath@sun.com To: Jack.Bochsler@sun.com Cc: David Kahn , Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam Message-id: <47C6E7E5.4070407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> <47C6E1A3.2060207@sun.com> <47C6E417.1020102@Sun.COM> User-Agent: Thunderbird 2.0.0.13pre (X11/20080218) Status: RO Content-Length: 2478 Well, if they changed open(2) to ignore the path that's passed in and use another one that's set using setpathtoopen(2) you might want that documented in the interfaces. That's what's going on here. The HV watchdog can be used successfully by just making use of these defined hypercalls. If you try to do the same with the ATCA watchdog without using other APIs that are "out of scope". Eduardo Jack.Bochsler@Sun.COM wrote: > Where does open(2) explain how NFS automounts a disk to > fullfill the call? > > IMO this is implementation in underlying the API, as above. > Initially there was a 1-1 mapping of the interface to an > implementation and it just worked. Note that there is no > documentation on the implementation (or limitations) of the > current SW WDT. > > So why does a second implementation of near identical > functionality get this new burden of detailing implementation? > > jack > > Eduardo E Horvath wrote the following on 02/28/08 08:30: >> David Kahn wrote: >>> >>> >>> Hitendra Zhangada wrote: >>> >>>> Yeah, but their application wants to use the same for both >>>> control and guest domains. I don't think it makes sense >>>> for application/daemon to check if it is control domain >>>> or guest domain and then use different set of APIs. >>> >>> I'm assuming that the application does know because >>> the application that pats the HW WD should be doing >>> it by IPMI (and attempted to do it via IPMI, but had >>> problems with that method) so it switched over to >>> this new interface, which was created to bypass the >>> microcontroller problems. If it wasn't for that >>> problem, they would be using IMPI only to interact >>> with the ATCA HW WD. At least that's how it was >>> explained to me. >>> >>> This is the first time I heard that they are using >>> the same application to pat the hw wd. >>> >>> I don't really care about this that much to derail >>> the case, so I'm not going to do that. >> >> >> Unless I'm missing something, this case only covers the patting >> of the ATCA watchdog, but does not give information about what >> is involved in setting the timeout, starting it, or stopping it. >> I don't really thing you should let this case be approved without >> such information in the case material. If anyone else tries to >> use this feature he should not find the need to add some secret >> magic sauce that's not documented or at least explicitly referred >> to in this case. >> >> >> -- Eduardo Horvath From sacadmin Thu Feb 28 17:24:28 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1T1ORYt025916 for ; Thu, 28 Feb 2008 17:24:28 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1T1ORE0031552; Thu, 28 Feb 2008 18:24:27 -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 <0JWZ003097WRH800@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 17:24:27 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWZ002YP7WQHP40@nwk-avmta-2.sfbay.sun.com>; Thu, 28 Feb 2008 17:24:26 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1T1OQZn028357; Thu, 28 Feb 2008 17:24:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWZ00K017RF1J00@fe-sfbay-10.sun.com> (original mail from Kevin.Song@Sun.COM); Thu, 28 Feb 2008 17:24:26 -0800 (PST) Received: from [129.145.155.91] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWZ00JCX7WOKG10@fe-sfbay-10.sun.com>; Thu, 28 Feb 2008 17:24:26 -0800 (PST) Date: Thu, 28 Feb 2008 17:24:24 -0800 From: Kevin Song Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6E7E5.4070407@sun.com> Sender: Kevin.Song@sun.com To: Eduardo E Horvath Cc: Jack.Bochsler@sun.com, David Kahn , Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam , Greg Onufer Message-id: <47C75EC8.90208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> <47C6E1A3.2060207@sun.com> <47C6E417.1020102@Sun.COM> <47C6E7E5.4070407@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2891 Now if we research for a new solution or new API, I like to point out. The nature of this new support in hv is GPIO support. The atca wdt patting is an application of GPIO (in FPGA), you can say. Will it be acceptable to define a new GPIO hv API, while the GPIO reg info (addr, bit definition) is platform specifc? Thanks, Kevin Eduardo E Horvath wrote: > > Well, if they changed open(2) to ignore the path that's > passed in and use another one that's set using setpathtoopen(2) > you might want that documented in the interfaces. That's > what's going on here. > > The HV watchdog can be used successfully by just making > use of these defined hypercalls. If you try to do the > same with the ATCA watchdog without using other APIs > that are "out of scope". > > Eduardo > > > Jack.Bochsler@Sun.COM wrote: >> Where does open(2) explain how NFS automounts a disk to >> fullfill the call? >> >> IMO this is implementation in underlying the API, as above. >> Initially there was a 1-1 mapping of the interface to an >> implementation and it just worked. Note that there is no >> documentation on the implementation (or limitations) of the >> current SW WDT. >> >> So why does a second implementation of near identical >> functionality get this new burden of detailing implementation? >> >> jack >> >> Eduardo E Horvath wrote the following on 02/28/08 08:30: >>> David Kahn wrote: >>>> >>>> >>>> Hitendra Zhangada wrote: >>>> >>>>> Yeah, but their application wants to use the same for both >>>>> control and guest domains. I don't think it makes sense >>>>> for application/daemon to check if it is control domain >>>>> or guest domain and then use different set of APIs. >>>> >>>> I'm assuming that the application does know because >>>> the application that pats the HW WD should be doing >>>> it by IPMI (and attempted to do it via IPMI, but had >>>> problems with that method) so it switched over to >>>> this new interface, which was created to bypass the >>>> microcontroller problems. If it wasn't for that >>>> problem, they would be using IMPI only to interact >>>> with the ATCA HW WD. At least that's how it was >>>> explained to me. >>>> >>>> This is the first time I heard that they are using >>>> the same application to pat the hw wd. >>>> >>>> I don't really care about this that much to derail >>>> the case, so I'm not going to do that. >>> >>> >>> Unless I'm missing something, this case only covers the patting >>> of the ATCA watchdog, but does not give information about what >>> is involved in setting the timeout, starting it, or stopping it. >>> I don't really thing you should let this case be approved without >>> such information in the case material. If anyone else tries to >>> use this feature he should not find the need to add some secret >>> magic sauce that's not documented or at least explicitly referred >>> to in this case. >>> >>> >>> > > From sacadmin Thu Feb 28 21:18:14 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1T5IEh5001946 for ; Thu, 28 Feb 2008 21:18:14 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1T5IBWD010826; Thu, 28 Feb 2008 21:18:13 -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 <0JWZ00C05IQB0600@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 22:18:11 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWZ0070RIQAPW80@brm-avmta-1.central.sun.com>; Thu, 28 Feb 2008 22:18:10 -0700 (MST) Received: from dtmail.sfbay.sun.com (dt101-150.SFBay.Sun.COM [10.6.101.150]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1T5IA8I041802; Thu, 28 Feb 2008 21:18:10 -0800 (PST) Received: from [127.0.0.1] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1T5I7iP025326; Thu, 28 Feb 2008 21:18:07 -0800 (PST) Date: Thu, 28 Feb 2008 21:18:07 -0800 From: David Kahn Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C75EC8.90208@sun.com> To: Kevin Song Cc: Eduardo E Horvath , Jack.Bochsler@sun.com, Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Raghunath Shenbagam , Greg Onufer Message-id: <47C7958F.9080601@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> <47C6E1A3.2060207@sun.com> <47C6E417.1020102@Sun.COM> <47C6E7E5.4070407@sun.com> <47C75EC8.90208@sun.com> User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) Status: RO Content-Length: 600 Kevin Song wrote: > Will it be acceptable to define a new GPIO hv API, while the GPIO reg > info (addr, bit definition) is platform specifc? Let's stick to creating functional interfaces. GPIO is a can of worms. (even without the HV there, it's a can of worms.) I think the reasonable choices are: 1. Live with the revised case. Accept that we're doing what's basically a hack to support ACTA, which is a large market for us. 2. Create a new API group/API for the hw wd that looks very similar to the one defined by the revised case. I can live with either solution. -David From sacadmin Fri Feb 29 16:20:13 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m210KD9n007435 for ; Fri, 29 Feb 2008 16:20:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m210KBg9019804; Fri, 29 Feb 2008 16:20:13 -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 <0JX000E03ZLNQ000@brm-avmta-1.central.sun.com>; Fri, 29 Feb 2008 17:20:11 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX000AXUZLMIJ20@brm-avmta-1.central.sun.com>; Fri, 29 Feb 2008 17:20:10 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m210KAa2024377; Fri, 29 Feb 2008 16:20:10 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX000201ZJTJA00@fe-sfbay-09.sun.com> (original mail from Raghunath.Shenbagam@Sun.COM); Fri, 29 Feb 2008 16:20:10 -0800 (PST) Received: from [129.145.155.24] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX000D33ZLL3GC0@fe-sfbay-09.sun.com>; Fri, 29 Feb 2008 16:20:10 -0800 (PST) Date: Fri, 29 Feb 2008 16:20:09 -0800 From: Raghunath Shenbagam Subject: Re: FWARC/2008/134 - revised material In-reply-to: <47C6E221.1050100@Sun.COM> Sender: Raghunath.Shenbagam@sun.com To: Raghunath.Shenbagam@sun.com Cc: David Kahn , Hitendra Zhangada , Firmware Arch , atca-wdt-dev@sun.com, Jack.Bochsler@sun.com Reply-to: Raghunath.Shenbagam@sun.com Message-id: <47C8A139.6060403@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C6877B.3080201@sun.com> <47C6E221.1050100@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2281 After discussing it in the project team meeting, the general consensus were to proceed with our current proposal(as describe in the updated doc.s). We discussed the option of creating a new api class for hw wdt, but if its going to be similar to what we have today, why have two similar api's if one can accommodate both? The current interface definitions were modified to look generic for a hw wdt api. If it does not fit well with a future (platform) hw wdt design, then this is a "hack" for atca wdt support. Thanks, Raghu Raghunath Shenbagam wrote: > David Kahn wrote: >> Hitendra Zhangada wrote: >>> Yeah, but their application wants to use the same for both >>> control and guest domains. I don't think it makes sense >>> for application/daemon to check if it is control domain >>> or guest domain and then use different set of APIs. > This is one of the goal for this project, we don't want to ask > the customer to change their application(in user land) that pat > watchdog timer. However, to accomodate LDOMs we may > have a s/w in the kernel that filter the IPMI cmds before sending > it down to the module that interface with hv. > >> I'm assuming that the application does know because >> the application that pats the HW WD should be doing >> it by IPMI (and attempted to do it via IPMI, but had >> problems with that method) so it switched over to >> this new interface, which was created to bypass the >> microcontroller problems. If it wasn't for that > Actually, we are creating a "shortcut" to IPMC. > IPMC can accept wdt patting from either IPMI msg or > in an intr. hdlr. IPMC provide a mechanism(intr pin) so > the payload(host) can trigger an interrupt instead of > a lengthy IPMI msg path. >> problem, they would be using IMPI only to interact >> with the ATCA HW WD. At least that's how it was >> explained to me. >> >> This is the first time I heard that they are using >> the same application to pat the hw wd. >> >> I don't really care about this that much to derail >> the case, so I'm not going to do that. > > Since we still have two lines of thought, one using the same > hv wdt api vs. defining a new api class that's fn. specific, > i'd like to take is back to the A-team(project team) and have this > discuss further. > > Thanks, > Raghu > From sacadmin Tue Mar 4 09:59:57 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m24Hxuql020798 for ; Tue, 4 Mar 2008 09:59:57 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m24Hxs2c005421; Tue, 4 Mar 2008 17:59:55 GMT 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 <0JX700B0ZWNULT00@brm-avmta-1.central.sun.com>; Tue, 04 Mar 2008 10:59:54 -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 <0JX700KRYWNQDMG0@brm-avmta-1.central.sun.com>; Tue, 04 Mar 2008 10:59:51 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m24Hxoa1014574; Tue, 04 Mar 2008 17:59:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX700701VXJ6I00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) ; Tue, 04 Mar 2008 10:59:50 -0700 (MST) Received: from [129.150.21.16] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX700KX0WNEGFC0@mail-amer.sun.com>; Tue, 04 Mar 2008 10:59:43 -0700 (MST) Date: Tue, 04 Mar 2008 09:59:38 -0800 From: Sunit Jain Subject: Re: FWARC/2008/134 - fast track - Hypervisor support for Hardware Watchdog timer In-reply-to: <47BE02F4.2010100@Sun.Com> Sender: S.Jain@sun.com To: Firmware Arch Cc: Raghunath.Shenbagam@sun.com, Jack.Bochsler@sun.com, atca-wdt-dev@sun.com Reply-to: S.Jain@sun.com Message-id: <47CD8E0A.6050805@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9b5uz+sZlZlKl0BHj+Cpag)" X-PMX-Version: 5.2.0.264296 References: <47BE02F4.2010100@Sun.Com> User-Agent: Thunderbird 2.0.0.12pre (Windows/20080123) Status: RO Content-Length: 1882 This is a multi-part message in MIME format. --Boundary_(ID_9b5uz+sZlZlKl0BHj+Cpag) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Case timer expired yesterday, case is now closed approved. IAM* file has been updated. Thanks, Sunit Sunit Jain wrote: > Update spec and interface table are copied in case material directory: > http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/ > > Since changes are small, I would like to extend timer for this case > to 3 more days, until Monday March 3, 2008. > Release Binding: > firmware: minor/micro firmware release > OS: minor/micro/patch OS release. > > --Boundary_(ID_9b5uz+sZlZlKl0BHj+Cpag) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Case timer expired yesterday, case is now closed approved. IAM* file has been updated.

Thanks,
Sunit


Sunit Jain wrote:
Update spec and interface table are copied in case material directory:
    http://sac.eng/Archives/CaseLog/arc/FWARC/2008/134/materials/

Since changes are small, I would like to extend timer for this case
to 3 more days, until Monday March 3, 2008.
Release Binding:
  firmware: minor/micro firmware release
  OS: minor/micro/patch OS release.


--Boundary_(ID_9b5uz+sZlZlKl0BHj+Cpag)--