|
[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 |