qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] seabios: add OSHP method stub


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH RFC] seabios: add OSHP method stub
Date: Tue, 14 Feb 2012 03:09:13 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]