From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WinhM-0006Gt-0M for qemu-devel@nongnu.org; Fri, 09 May 2014 12:31:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WinhE-0003CV-68 for qemu-devel@nongnu.org; Fri, 09 May 2014 12:30:59 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:49543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WinhE-0003CL-12 for qemu-devel@nongnu.org; Fri, 09 May 2014 12:30:52 -0400 Message-ID: <536D029C.2060407@citrix.com> Date: Fri, 9 May 2014 12:30:20 -0400 From: Ross Philipson MIME-Version: 1.0 References: <1399625235-8216-1-git-send-email-arei.gonglei@huawei.com> <536CBD840200007800010D2D@mail.emea.novell.com> <33183CC9F5247A488A2544077AF19020815E7487@SZXEMA503-MBS.china.huawei.com> <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> In-Reply-To: <1399651933.561.56.camel@kazak.uk.xensource.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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: Ian Campbell , Konrad Rzeszutek Wilk Cc: "Huangweidong (C)" , "Gonglei (Arei)" , "mst@redhat.com" , "Hanweidong (Randy)" , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , "fabio.fantoni@m2r.biz" , Anthony Perard , "kevin@koconnor.net" , Stefano Stabellini , Jan Beulich , "johannes.krampf@googlemail.com" , "Gaowei (UVP)" , Paul Durrant On 05/09/2014 12:12 PM, Ian Campbell wrote: > 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) Yea that is a good point. Windows probably cannot survive the attempt to eject. The spec sort of implies the OSPM should check to see that it was ejected properly but nothing about how a failed eject would be handled. "OSPM verifies the device no longer exists to determine if the eject succeeded." And then BSODs... > > Ian. > > > ----- > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Philipson Subject: Re: [PATCH v4] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching Date: Fri, 9 May 2014 12:30:20 -0400 Message-ID: <536D029C.2060407@citrix.com> References: <1399625235-8216-1-git-send-email-arei.gonglei@huawei.com> <536CBD840200007800010D2D@mail.emea.novell.com> <33183CC9F5247A488A2544077AF19020815E7487@SZXEMA503-MBS.china.huawei.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1399651933.561.56.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Konrad Rzeszutek Wilk Cc: "Huangweidong (C)" , "Gonglei (Arei)" , "mst@redhat.com" , "Hanweidong (Randy)" , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , "fabio.fantoni@m2r.biz" , Anthony Perard , "kevin@koconnor.net" , Stefano Stabellini , Jan Beulich , "johannes.krampf@googlemail.com" , "Gaowei (UVP)" , Paul Durrant List-Id: xen-devel@lists.xenproject.org On 05/09/2014 12:12 PM, Ian Campbell wrote: > 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) Yea that is a good point. Windows probably cannot survive the attempt to eject. The spec sort of implies the OSPM should check to see that it was ejected properly but nothing about how a failed eject would be handled. "OSPM verifies the device no longer exists to determine if the eject succeeded." And then BSODs... > > Ian. > > > ----- > 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