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.