From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wip1U-0001jb-Jl for qemu-devel@nongnu.org; Fri, 09 May 2014 13:55:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wip1P-0007tc-3I for qemu-devel@nongnu.org; Fri, 09 May 2014 13:55:52 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:45220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wip1O-0007tK-LT for qemu-devel@nongnu.org; Fri, 09 May 2014 13:55:47 -0400 Date: Fri, 9 May 2014 13:55:29 -0400 From: Konrad Rzeszutek Wilk Message-ID: <20140509175529.GA8108@phenom.dumpdata.com> References: <1399629430.9513.143.camel@kazak.uk.xensource.com> <33183CC9F5247A488A2544077AF19020815E74DA@SZXEMA503-MBS.china.huawei.com> <1399631195.9513.149.camel@kazak.uk.xensource.com> <20140509132553.GA3057@phenom.dumpdata.com> <1399642266.561.14.camel@kazak.uk.xensource.com> <536CE879.4050303@citrix.com> <20140509160039.GA5721@phenom.dumpdata.com> <1399651933.561.56.camel@kazak.uk.xensource.com> <9AAE0902D5BC7E449B7C8E4E778ABCD034E037@AMSPEX01CL01.citrite.net> <536D114A.3050409@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <536D114A.3050409@citrix.com> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ross Philipson Cc: "Huangweidong (C)" , Ian Campbell , "mst@redhat.com" , "Hanweidong (Randy)" , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , "fabio.fantoni@m2r.biz" , Anthony Perard , "Gonglei (Arei)" , "kevin@koconnor.net" , Stefano Stabellini , "Gaowei (UVP)" , Jan Beulich , "johannes.krampf@googlemail.com" , Paul Durrant On Fri, May 09, 2014 at 01:32:58PM -0400, Ross Philipson wrote: > On 05/09/2014 12:34 PM, Paul Durrant wrote: > >>-----Original Message----- > >>From: Ian Campbell > >>Sent: 09 May 2014 17:12 > >>To: Konrad Rzeszutek Wilk > >>Cc: Ross Philipson; kevin@koconnor.net; Huangweidong (C); Hanweidong > >>(Randy); mst@redhat.com; qemu-devel@nongnu.org; xen- > >>devel@lists.xen.org; fabio.fantoni@m2r.biz; > >>johannes.krampf@googlemail.com; Gonglei (Arei); Stefano Stabellini; > >>Gaowei (UVP); Jan Beulich; Anthony Perard; Paul Durrant > >>Subject: Re: [Xen-devel] [PATCH v4] Hvmloader: Modify ACPI to only supply > >>_EJ0 methods for PCIslots that support hotplug by runtime patching > >> > >>On Fri, 2014-05-09 at 12:00 -0400, Konrad Rzeszutek Wilk wrote: > >> > >>>So we could just then gat the _EJ0 functionality based on values that > >>>are present (or not) in the SSDT ? > >> > >>AIUI the very presence of _EJ0 is what marks the device as being > >>ejectable (e.g. in the Windows device manager). > >> > >>It would be possible to make _EJ0 conditionally turn itself into a NOP > >>without resorting to an SSDT, but I don't think that solves the issue > >>they are trying to solve, which is that the user can even try to eject > >>an non-hotplug device. (grep for UAR1 in our dsdt.asl and > >>acpi_info->com1_present in hvmloader/acpi/build.c for an example of this > >>sort of conditional thing) > >> > > Going back to the SSDT idea. A little poking around and what not and I came > up with something like this that I build into an SSDT: > > DefinitionBlock ("SSDTX.aml", "SSDT", 2, "Xen", "HVM", 0) > { > /* S00 device is defined in DSDT, this allows me to > * refrence it in this SSDT > */ > External (\_SB.PCI0.S00, DeviceObj) > > ... > > /* Extend the functionality of S00 */ > Scope ( \_SB.PCI0.S00 ) { > Method(_EJ0, 1, NotSerialized) > { > /* Do stuffs here */ > } > } > } Oh nice. That certainly would be neater then my idea. > > So I did find some examples of this after all in my pile of ACPI firmware > snapshots from all our supported platforms. I think this would work allowing > you to just add or not add _EJ0 methods to the PCI devices you want by > either using different SSDTs or doing something to generate or munge the > SSDT at runtime (which would be simpler than messing with the DSDT I think. > I did not try it (actually I did but ran into other problems on our platform > :). :-) > > > > >Yes, ejectable is only part of it. If there's appropriate AML for the slot, it is enough to indicate that a device is removable. I found the following link to an old M$ doc describing hotplug PCI: http://www.microsoft.com/china/whdc/system/pnppwr/hotadd/hotplugpci.mspx. (There's a load of Chinese characters surrounding the doc, but the body is in English). > > > > Paul > > > >----- > >No virus found in this message. > >Checked by AVG - www.avg.com > >Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14 > > > > > -- > Ross Philipson