Re: [SeaBIOS] [PATCH RFC] seabios: add OSHP method stub

2012-02-29 Thread Gerd Hoffmann 
 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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-02-14 Thread Paul Brook 
  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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-02-14 Thread Michael S. Tsirkin 
On Tue, Feb 14, 2012 at 12:49:08PM +, 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.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-02-14 Thread Paul Brook 
   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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2012-02-14 Thread Michael S. Tsirkin 
On Tue, Feb 14, 2012 at 01:47:59PM +, 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.

-- 
MMST
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC] seabios: add OSHP method stub

2012-02-13 Thread Michael S. Tsirkin 
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 m...@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)
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] seabios: add OSHP method stub

2012-02-13 Thread Kevin O'Connor 
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] seabios: add OSHP method stub

2012-02-13 Thread Kevin O'Connor 
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] seabios: add OSHP method stub

2012-02-13 Thread Michael S. Tsirkin 
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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] seabios: add OSHP method stub

2012-02-13 Thread Michael S. Tsirkin 
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.


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html