[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] tools/firmware: remove "_PS0/3" Method
> Have you tested any other OSes? How does Windows for example respond to > this change in the ACPI tables? > Yes, I did some test with this patch, till now, all result shows patch works well with PCI device assign and hotplug, as well as HVM S3. Pass cases: RHEL6.1, SLES11 SP1, Win2008 VF device assign and hotplug. RHEL6.1, Winxp, Win7 e1000e NIC device assign and hotplug RHEL6.1, RHEL5.1 Guest S3 > Are there any devices which do not implement PCI PM and therefore rely on > this ACPI mechanism to function? My understanding was that > 47e9037ac166 was required in part due to the lack of PCI PM support on some > VF devices. I think it was a different Intel SR-IOV NIC than the one you are > testing, an 82559 if [0] is to be believed. > VF is such device which do not have PCI PM capability, these device will be set PCI_D0 directly in function pci_platform_power_transition(). static int pci_platform_power_transition(struct pci_dev *dev, pci_power_t state) { int error; if (platform_pci_power_manageable(dev)) { error = platform_pci_set_power_state(dev, state); ... } else { error = -ENODEV; /* Fall back to PCI_D0 if native PM is not supported */ if (!dev->pm_cap) dev->current_state = PCI_D0; > Also there was a previous attempt to remove _PS0 in [1]. Allen Kay (CCd) > tested > and reported that removing these values causes Windows not to boot. It was > suggested in that thread that both _PS0 and _PS3 need to be removed (which > you do) but it was also suggested that doing so breaks Linux S3 support, have > you tried this? > Windows does not to boot only happen when remove _PS0, however Windows guest can boot up with removing _PS0 and _PS3. According to the annotate of "_PS0/3", it's for debug purpose. I do not know whether it's required for other purpose, comments of others? Thanks, -Xudong > Ian. > > [0] > http://old-list-archives.xen.org/archives/html/xen-devel/2011-03/msg00434.ht > ml > [1] > http://old-list-archives.xen.org/archives/html/xen-devel/2011-02/threads.html > > > > > > > Ian. > > > > > > > > > > > Signed-off-by: Xudong Hao <xudong.hao@xxxxxxxxx> > > > > Signed-off-by: Haitao Shan <haitao.shan@xxxxxxxxx> > > > > > > > > diff -r df7cec2c6c03 tools/firmware/hvmloader/acpi/mk_dsdt.c > > > > --- a/tools/firmware/hvmloader/acpi/mk_dsdt.c Tue Nov 29 13:30:39 > > > 2011 -0500 > > > > +++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c Wed Nov 30 > 15:08:20 > > > 2011 +0800 > > > > @@ -323,8 +323,6 @@ > > > > * the ACPI event: > > > > * _EJ0: eject a device > > > > * _STA: return a device's status, e.g. enabled or removed > > > > - * Other methods are optional: > > > > - * _PS0/3: put them here for debug purpose > > > > * > > > > * Eject button would generate a general-purpose event, then the > > > > * control method for this event uses Notify() to inform OSPM > > > > which > > > @@ -344,13 +342,6 @@ > > > > stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | > > > > (slot & > > > 7)); > > > > /* _SUN == dev */ > > > > stmt("Name", "_SUN, 0x%08x", slot >> 3); > > > > - push_block("Method", "_PS0, 0"); > > > > - stmt("Store", "0x%02x, \\_GPE.DPT1", slot); > > > > - stmt("Store", "0x80, \\_GPE.DPT2"); > > > > - pop_block(); > > > > - push_block("Method", "_PS3, 0"); > > > > - stmt("Store", "0x%02x, \\_GPE.DPT1", slot); > > > > - stmt("Store", "0x83, \\_GPE.DPT2"); > > > > pop_block(); > > > > push_block("Method", "_EJ0, 1"); > > > > stmt("Store", "0x%02x, \\_GPE.DPT1", slot) > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@xxxxxxxxxxxxxxxxxxx > > > > http://lists.xensource.com/xen-devel > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |