To allow guests to load the native SHPC driver for a bridge, we must declare an OSHP method for the appropriate device which lets the OS take control of the SHPC. As we don't access SHPC at the moment, we don't need to do anything - just report success.
Signed-off-by: Michael S. Tsirkin mst@redhat.com
---
diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl index 442e7a8..3f50169 100644 --- a/src/ssdt-pcihp.dsl +++ b/src/ssdt-pcihp.dsl @@ -24,6 +24,7 @@ DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1) ACPI_EXTRACT_METHOD_STRING aml_ej0_name \ Method (_EJ0, 1) { Return(PCEJ(0x##slot)) } \ Name (_SUN, 0x##slot) \ + Method (OSHP, 1) { Return(0x0) } \ }
hotplug_slot(03)
On Mon, Feb 13, 2012 at 11:33:08AM +0200, Michael S. Tsirkin wrote:
To allow guests to load the native SHPC driver for a bridge, we must declare an OSHP method for the appropriate device which lets the OS take control of the SHPC. As we don't access SHPC at the moment, we don't need to do anything - just report success.
The patch is fine with me, but since this is really qemu/kvm specific, please provide an ack from one of the qemu/kvm maintainers.
-Kevin
On Mon, Feb 13, 2012 at 07:34:55PM -0500, Kevin O'Connor wrote:
On Mon, Feb 13, 2012 at 11:33:08AM +0200, Michael S. Tsirkin wrote:
To allow guests to load the native SHPC driver for a bridge, we must declare an OSHP method for the appropriate device which lets the OS take control of the SHPC. As we don't access SHPC at the moment, we don't need to do anything - just report success.
The patch is fine with me, but since this is really qemu/kvm specific, please provide an ack from one of the qemu/kvm maintainers.
-Kevin
I expect no problem with this, though I'm wondering what makes it qemu specific.
On Tue, Feb 14, 2012 at 02:43:45AM +0200, Michael S. Tsirkin wrote:
On Mon, Feb 13, 2012 at 07:34:55PM -0500, Kevin O'Connor wrote:
On Mon, Feb 13, 2012 at 11:33:08AM +0200, Michael S. Tsirkin wrote:
To allow guests to load the native SHPC driver for a bridge, we must declare an OSHP method for the appropriate device which lets the OS take control of the SHPC. As we don't access SHPC at the moment, we don't need to do anything - just report success.
The patch is fine with me, but since this is really qemu/kvm specific, please provide an ack from one of the qemu/kvm maintainers.
-Kevin
I expect no problem with this, though I'm wondering what makes it qemu specific.
Only kvm/qemu use the ACPI tables in seabios.
In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking for an additional Ack.
-Kevin
On Mon, Feb 13, 2012 at 07:48:37PM -0500, Kevin O'Connor wrote:
On Tue, Feb 14, 2012 at 02:43:45AM +0200, Michael S. Tsirkin wrote:
On Mon, Feb 13, 2012 at 07:34:55PM -0500, Kevin O'Connor wrote:
On Mon, Feb 13, 2012 at 11:33:08AM +0200, Michael S. Tsirkin wrote:
To allow guests to load the native SHPC driver for a bridge, we must declare an OSHP method for the appropriate device which lets the OS take control of the SHPC. As we don't access SHPC at the moment, we don't need to do anything - just report success.
The patch is fine with me, but since this is really qemu/kvm specific, please provide an ack from one of the qemu/kvm maintainers.
-Kevin
I expect no problem with this, though I'm wondering what makes it qemu specific.
Only kvm/qemu use the ACPI tables in seabios.
In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking for an additional Ack.
-Kevin
No problem, I'll get an Ack :) Meanwhile - here's a summary, as far as I understand it.
Originally PCI SIG only defined the electrical and mechanical requirements from hotplug, no standard software interface. So it needed ACPI to drive device-specific registers to actually do hotplug. At some point PCISIG defined standard interfaces for PCI hotplug. There are two of them: standard hot plug controller (SHPC) for PCI and PCIE hotplug for Express.
Now an OS can have a standard driver and use it to activate hotplug functionality. This is OS hotplug (OSHP).
But what about older OSes that do not have this driver? ACPI can support these by driving the SHPC interface itself. This will work but then it can conflict with the new driver in the OS.
To solve the problem, OS tells ACPI to leave SHPC alone. There are two things OS tries to activate to do this, in this order: 1. _OSC for global switch to native SHPC driver 2. OSHP for switch on the given bridge device
If none of the above are present, or if they fail, OS assumes ACPI wants control of the SHPC registers and won't touch them.
Hope above makes sense.
In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking for an additional Ack.
No problem, I'll get an Ack :) Meanwhile - here's a summary, as far as I understand it.
Originally PCI SIG only defined the electrical and mechanical requirements from hotplug, no standard software interface. So it needed ACPI to drive device-specific registers to actually do hotplug. At some point PCISIG defined standard interfaces for PCI hotplug. There are two of them: standard hot plug controller (SHPC) for PCI and PCIE hotplug for Express.
Now an OS can have a standard driver and use it to activate hotplug functionality. This is OS hotplug (OSHP).
So presumably this will work on targets that don't have ACPI? Assuming a competent guest OS of course. Have you tested this?
Paul
On Tue, Feb 14, 2012 at 12:49:08PM +0000, Paul Brook wrote:
In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking for an additional Ack.
No problem, I'll get an Ack :) Meanwhile - here's a summary, as far as I understand it.
Originally PCI SIG only defined the electrical and mechanical requirements from hotplug, no standard software interface. So it needed ACPI to drive device-specific registers to actually do hotplug. At some point PCISIG defined standard interfaces for PCI hotplug. There are two of them: standard hot plug controller (SHPC) for PCI and PCIE hotplug for Express.
Now an OS can have a standard driver and use it to activate hotplug functionality. This is OS hotplug (OSHP).
So presumably this will work on targets that don't have ACPI? Assuming a competent guest OS of course. Have you tested this?
Paul
This being the qemu side of things? I run Linux and verified that it calls OSHP and afterwards, runs the native driver and handles hotplug/unplug without invoking ACPI at all.
It seems that at least the SHPC driver in linux doesn't work if you don't have an acpi table with the OSHP method - not many people run with acpi=off nowdays, so it's probably just a bug. I'll check how hard it is to fix this.
Now an OS can have a standard driver and use it to activate hotplug functionality. This is OS hotplug (OSHP).
So presumably this will work on targets that don't have ACPI? Assuming a competent guest OS of course. Have you tested this?
This being the qemu side of things? I run Linux and verified that it calls OSHP and afterwards, runs the native driver and handles hotplug/unplug without invoking ACPI at all.
I mean using your shiny new hotplug PCI-PCI bridge on arm/ppc/mips targets (i.e anything other than x86 PC). From your description it sounds like it *should* work.
It seems that at least the SHPC driver in linux doesn't work if you don't have an acpi table with the OSHP method - not many people run with acpi=off nowdays, so it's probably just a bug. I'll check how hard it is to fix this.
Targets other than x86 don't have ACPI to start with.
Paul
On Tue, Feb 14, 2012 at 01:47:59PM +0000, Paul Brook wrote:
Now an OS can have a standard driver and use it to activate hotplug functionality. This is OS hotplug (OSHP).
So presumably this will work on targets that don't have ACPI? Assuming a competent guest OS of course. Have you tested this?
This being the qemu side of things? I run Linux and verified that it calls OSHP and afterwards, runs the native driver and handles hotplug/unplug without invoking ACPI at all.
I mean using your shiny new hotplug PCI-PCI bridge on arm/ppc/mips targets (i.e anything other than x86 PC). From your description it sounds like it *should* work.
It seems that at least the SHPC driver in linux doesn't work if you don't have an acpi table with the OSHP method - not many people run with acpi=off nowdays, so it's probably just a bug. I'll check how hard it is to fix this.
Targets other than x86 don't have ACPI to start with.
Paul
So
#ifdef CONFIG_ACPI #include <linux/pci-acpi.h> static inline int get_hp_hw_control_from_firmware(struct pci_dev *dev) { u32 flags = OSC_SHPC_NATIVE_HP_CONTROL; return acpi_get_hp_hw_control_from_firmware(dev, flags); } #else #define get_hp_hw_control_from_firmware(dev) (0) #endif
So if you build your guest without acpi, things should work fine.
diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl index 442e7a8..3f50169 100644 --- a/src/ssdt-pcihp.dsl +++ b/src/ssdt-pcihp.dsl @@ -24,6 +24,7 @@ DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1) ACPI_EXTRACT_METHOD_STRING aml_ej0_name \ Method (_EJ0, 1) { Return(PCEJ(0x##slot)) } \ Name (_SUN, 0x##slot) \
Method (OSHP, 1) { Return(0x0) } \ }
Linux kernel (kernel-3.2.7-1.fc16.x86_64) complains:
ACPI Warning: For _SB_.PCI0.S10_.OSHP: Insufficient arguments - needs 1, found 0 (20110623/nspredef-321)
cheers, Gerd
-
Gerd Hoffmann -
Kevin O'Connor -
Michael S. Tsirkin -
Paul Brook