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.
On Mon, Feb 13, 2012 at 07:34:55PM -0500, Kevin
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.
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.
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
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.