This patch removes all the _PS0 entries from the DSDT.
The reason for removing them is that if a passthrough device doesn't
have power management capabilities declared in its pci config space but
_PS0 is declared in the DSDT a Linux HVM guest gets confused and cannot
set the device to D0. In order to reproduce this problem you can try to
assign a VF to a Linux HVM guest, the result is a guest kernel crash as
reported in this bug:
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1742.
I tested this patch with Linux and Windows guests and it looks like it
is not breaking anything (guest S3 in particular is working).
However I am afraid it could cause unwanted side effects, specifically
it could break gfx passthrough of Intel GPUs (I haven't tested this on xen
4.1 but it looks like it would break gfx passthrough on xen 3.4).
Could anyone from Intel confirm whether this patch is correct or might
cause any problems?
Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
diff -r 13a7d1f7f62c tools/firmware/hvmloader/acpi/mk_dsdt.c
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c Mon Feb 21 09:11:57 2011 +0000
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c Wed Feb 23 12:27:35 2011 +0000
@@ -252,7 +252,6 @@ int main(int argc, char **argv)
* _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
@@ -271,10 +270,6 @@ int main(int argc, char **argv)
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");
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|