[Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support

Aleksandr Bezzubikov posted 6 patches 6 years, 9 months ago
Failed in applying to current master (apply log)
hw/acpi/ich9.c         |  31 +++++++++++++
hw/i386/acpi-build.c   | 116 ++++++++++++++++++++++++-------------------------
hw/isa/lpc_ich9.c      |  12 +++++
include/hw/acpi/ich9.h |   4 ++
include/hw/i386/pc.h   |   7 ++-
5 files changed, 111 insertions(+), 59 deletions(-)
[Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Aleksandr Bezzubikov 6 years, 9 months ago
The series adds hotplug support to legacy PCI buses for Q35 machines.
The ACPI hotplug code is emitted if at least one legacy pci-bridge is present.

This series is mostly based on past Marcel's series 
https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg05681.html,
but rebased on current master with some minor changes according to current codebase.

ACPI code emission approach used in this series can be called "static", 
because it checkswhether a bridge exists only at initial DSDT generation moment. 
The main goal is to enable AML PCI hotplug-related code to be generated dynamically. 
In other words, the bridge plugged in - a new acpi definition block is
loaded (using LoadTable method). 
This is necessary for PCIE-PCI bridge hotplugging feature. 

Aleksandr Bezzubikov (6):
  hw/acpi: remove dead acpi code
  hw/acpi: simplify dsdt building code
  hw/acpi: fix pcihp io initialization
  hw/acpi: prepare pci hotplug IO for ich9
  hw/acpi: extend acpi pci hotplug support for pci express
  hw/ich9: enable acpi pci hotplug

 hw/acpi/ich9.c         |  31 +++++++++++++
 hw/i386/acpi-build.c   | 116 ++++++++++++++++++++++++-------------------------
 hw/isa/lpc_ich9.c      |  12 +++++
 include/hw/acpi/ich9.h |   4 ++
 include/hw/i386/pc.h   |   7 ++-
 5 files changed, 111 insertions(+), 59 deletions(-)

-- 
2.7.4


Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Michael S. Tsirkin 6 years, 9 months ago
On Fri, Jun 30, 2017 at 12:55:56AM +0300, Aleksandr Bezzubikov wrote:
> The series adds hotplug support to legacy PCI buses for Q35 machines.
> The ACPI hotplug code is emitted if at least one legacy pci-bridge is present.
> 
> This series is mostly based on past Marcel's series 
> https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg05681.html,
> but rebased on current master with some minor changes according to current codebase.
> 
> ACPI code emission approach used in this series can be called "static", 
> because it checkswhether a bridge exists only at initial DSDT generation moment. 
> The main goal is to enable AML PCI hotplug-related code to be generated dynamically. 
> In other words, the bridge plugged in - a new acpi definition block is
> loaded (using LoadTable method). 
> This is necessary for PCIE-PCI bridge hotplugging feature. 

I wonder whether we really need ACPI hotplug.
Most modern systems are limited to native PCIE.

I do understand the need to add PCI devices sometimes,
but maybe we can find a way to do this with native hotplug.

For example, how about the following approach


- PCIE downstream port - X - PCIE-to-PCI bridge - PCI device


By hotplugging the bridge+device combination into a downstream
port (point X) we can potentially make devices enumerate
properly.

This might cause some issues with IO port assignment (uses 4K
io port space due to bridge aperture limitations)
but maybe we do not need so many legacy PCI devices -
people who do can simply use piix.


For this to work we need a way to create bridge instance
that is invisible to the guest. There is already a
way to do this for multifunction devices:

create bridge in function != 0
attach device
then create a dummy function 0

Inelegant - it would be cleaner to support this for function 0
as well - but should allow you to test the idea directly.



> Aleksandr Bezzubikov (6):
>   hw/acpi: remove dead acpi code
>   hw/acpi: simplify dsdt building code
>   hw/acpi: fix pcihp io initialization
>   hw/acpi: prepare pci hotplug IO for ich9
>   hw/acpi: extend acpi pci hotplug support for pci express
>   hw/ich9: enable acpi pci hotplug
> 
>  hw/acpi/ich9.c         |  31 +++++++++++++
>  hw/i386/acpi-build.c   | 116 ++++++++++++++++++++++++-------------------------
>  hw/isa/lpc_ich9.c      |  12 +++++
>  include/hw/acpi/ich9.h |   4 ++
>  include/hw/i386/pc.h   |   7 ++-
>  5 files changed, 111 insertions(+), 59 deletions(-)
> 
> -- 
> 2.7.4

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Marcel Apfelbaum 6 years, 9 months ago
On 30/06/2017 2:17, Michael S. Tsirkin wrote:
> On Fri, Jun 30, 2017 at 12:55:56AM +0300, Aleksandr Bezzubikov wrote:
>> The series adds hotplug support to legacy PCI buses for Q35 machines.
>> The ACPI hotplug code is emitted if at least one legacy pci-bridge is present.
>>
>> This series is mostly based on past Marcel's series
>> https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg05681.html,
>> but rebased on current master with some minor changes according to current codebase.
>>
>> ACPI code emission approach used in this series can be called "static",
>> because it checkswhether a bridge exists only at initial DSDT generation moment.
>> The main goal is to enable AML PCI hotplug-related code to be generated dynamically.
>> In other words, the bridge plugged in - a new acpi definition block is
>> loaded (using LoadTable method).
>> This is necessary for PCIE-PCI bridge hotplugging feature.
> 

Hi Michael,
Thank you for looking into this.

> I wonder whether we really need ACPI hotplug.
> Most modern systems are limited to native PCIE.
> 

I was under impression that ACPI hotplug will still remain
for memory/cpu hotplug, but I might be wrong. If this
is the case (ACPI hotplug is used for other subsystems),
I don't see why modern system would disable the PCI APCI hoptplug.
(I am not saying PCIe hotplug is not preferred.)

And if the modern systems are limited to native PCIe
we might have a bigger problem since the QEMU default
x86 machine is PCI based and we don't have PCIe obviously...
maybe is this the right time to switch to Q35 as the default machine?
(I am aware it should be a different discussion)


> I do understand the need to add PCI devices sometimes,
> but maybe we can find a way to do this with native hotplug.
> 
> For example, how about the following approach
> 
> 
> - PCIE downstream port - X - PCIE-to-PCI bridge - PCI device
> 

It can be a solution, yes, but then we would limit (seriously)
the number of PCI devices we can add. It will not be a problem
if we will continue to keep Q35 for "modern systems" only machine
and keep PC around as the default machine. However adding full support
for pci-bridge will allow us to switch to Q35 and use it
as the default machine (sometime sooner) since it would
be easier to map older configurations.

> 
> By hotplugging the bridge+device combination into a downstream
> port (point X) we can potentially make devices enumerate
> properly.
> 

It may work, yes, Alexandr will you be willing to try it?

> This might cause some issues with IO port assignment (uses 4K
> io port space due to bridge aperture limitations)
> but maybe we do not need so many legacy PCI devices -
> people who do can simply use piix.
> 

IO port assignment issue can be solved by using non standard
IO port space, some OSes can actually deal with it (I think),
however it will not solve the limitation of the number of
pci devices we can have, since each device (PCIe or not) will be
under a different bus we will have 256 PCI devices max.
We can use multi-functions, but then the hot-plug granularity
goes away.

> 
> For this to work we need a way to create bridge instance
> that is invisible to the guest. There is already a
> way to do this for multifunction devices:
> 
> create bridge in function != 0
> attach device
> then create a dummy function 0
> 
> Inelegant - it would be cleaner to support this for function 0
> as well - but should allow you to test the idea directly.
> 

The benefit of this project is to  make Q35 a "wider" machine
that would include all prev QEMU devices and will facilitate
the transition from the pc to q35 machine.

So for the modern systems not supporting PCI ACPI hotplug
we don't need pci-bridges anyway, but for the older ones
the ACPI code of the pci-bridge will be loaded into the
ACPI namespace only if a pci-bridge is actually hot-plugged.

That being said, if we decide that q35 will be used for
modern systems only and the pc machine will remain the
default for the next years, we may try to bundle
the pci-bridge with the device/s behind it.

Thanks,
Marcel

> 
> 
>> Aleksandr Bezzubikov (6):
>>    hw/acpi: remove dead acpi code
>>    hw/acpi: simplify dsdt building code
>>    hw/acpi: fix pcihp io initialization
>>    hw/acpi: prepare pci hotplug IO for ich9
>>    hw/acpi: extend acpi pci hotplug support for pci express
>>    hw/ich9: enable acpi pci hotplug
>>
>>   hw/acpi/ich9.c         |  31 +++++++++++++
>>   hw/i386/acpi-build.c   | 116 ++++++++++++++++++++++++-------------------------
>>   hw/isa/lpc_ich9.c      |  12 +++++
>>   include/hw/acpi/ich9.h |   4 ++
>>   include/hw/i386/pc.h   |   7 ++-
>>   5 files changed, 111 insertions(+), 59 deletions(-)
>>
>> -- 
>> 2.7.4


Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Michael S. Tsirkin 6 years, 9 months ago
On Fri, Jun 30, 2017 at 10:25:05AM +0300, Marcel Apfelbaum wrote:
> On 30/06/2017 2:17, Michael S. Tsirkin wrote:
> > On Fri, Jun 30, 2017 at 12:55:56AM +0300, Aleksandr Bezzubikov wrote:
> > > The series adds hotplug support to legacy PCI buses for Q35 machines.
> > > The ACPI hotplug code is emitted if at least one legacy pci-bridge is present.
> > > 
> > > This series is mostly based on past Marcel's series
> > > https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg05681.html,
> > > but rebased on current master with some minor changes according to current codebase.
> > > 
> > > ACPI code emission approach used in this series can be called "static",
> > > because it checkswhether a bridge exists only at initial DSDT generation moment.
> > > The main goal is to enable AML PCI hotplug-related code to be generated dynamically.
> > > In other words, the bridge plugged in - a new acpi definition block is
> > > loaded (using LoadTable method).
> > > This is necessary for PCIE-PCI bridge hotplugging feature.
> > 
> 
> Hi Michael,
> Thank you for looking into this.
> 
> > I wonder whether we really need ACPI hotplug.
> > Most modern systems are limited to native PCIE.
> > 
> 
> I was under impression that ACPI hotplug will still remain
> for memory/cpu hotplug, but I might be wrong. If this
> is the case (ACPI hotplug is used for other subsystems),
> I don't see why modern system would disable the PCI APCI hoptplug.
> (I am not saying PCIe hotplug is not preferred.)
> 
> And if the modern systems are limited to native PCIe
> we might have a bigger problem since the QEMU default
> x86 machine is PCI based and we don't have PCIe obviously...
> maybe is this the right time to switch to Q35 as the default machine?
> (I am aware it should be a different discussion)
> 
> 
> > I do understand the need to add PCI devices sometimes,
> > but maybe we can find a way to do this with native hotplug.
> > 
> > For example, how about the following approach
> > 
> > 
> > - PCIE downstream port - X - PCIE-to-PCI bridge - PCI device
> > 
> 
> It can be a solution, yes, but then we would limit (seriously)
> the number of PCI devices we can add. It will not be a problem
> if we will continue to keep Q35 for "modern systems" only machine
> and keep PC around as the default machine. However adding full support
> for pci-bridge will allow us to switch to Q35 and use it
> as the default machine (sometime sooner) since it would
> be easier to map older configurations.

Part of the value from where I stand is dropping support for
a large matrix of configurations, without hurting users.
So we maintain piix but add features to q35 only.

Where are these pci devices coming from that you need such a large
number of them?  Part of the issue is things like sound, but these
aren't even always hotpluggable.

> > 
> > By hotplugging the bridge+device combination into a downstream
> > port (point X) we can potentially make devices enumerate
> > properly.
> > 
> 
> It may work, yes, Alexandr will you be willing to try it?
> 
> > This might cause some issues with IO port assignment (uses 4K
> > io port space due to bridge aperture limitations)
> > but maybe we do not need so many legacy PCI devices -
> > people who do can simply use piix.
> > 
> 
> IO port assignment issue can be solved by using non standard
> IO port space, some OSes can actually deal with it (I think),
> however it will not solve the limitation of the number of
> pci devices we can have, since each device (PCIe or not) will be
> under a different bus we will have 256 PCI devices max.
> We can use multi-functions, but then the hot-plug granularity
> goes away.

That's quite a lot. SRIOV systems sometimes go higher because
people expose each VF as a separate device to the guest,
but these almost always
. are pcie
. have no io space

> > 
> > For this to work we need a way to create bridge instance
> > that is invisible to the guest. There is already a
> > way to do this for multifunction devices:
> > 
> > create bridge in function != 0
> > attach device
> > then create a dummy function 0
> > 
> > Inelegant - it would be cleaner to support this for function 0
> > as well - but should allow you to test the idea directly.
> > 
> 
> The benefit of this project is to  make Q35 a "wider" machine
> that would include all prev QEMU devices and will facilitate
> the transition from the pc to q35 machine.

But it's not a given that it's a win. We carry in a bunch of
crappy half-way supported devices. No way to drop them from piix.

> So for the modern systems not supporting PCI ACPI hotplug
> we don't need pci-bridges anyway, but for the older ones
> the ACPI code of the pci-bridge will be loaded into the
> ACPI namespace only if a pci-bridge is actually hot-plugged.
> 
> That being said, if we decide that q35 will be used for
> modern systems only and the pc machine will remain the
> default for the next years, we may try to bundle
> the pci-bridge with the device/s behind it.
> 
> Thanks,
> Marcel

I'm not sure it matters what the default is, but yea.
Let's look at the big picture, yes we can add a PV interface
and support this, but should we?

> > 
> > 
> > > Aleksandr Bezzubikov (6):
> > >    hw/acpi: remove dead acpi code
> > >    hw/acpi: simplify dsdt building code
> > >    hw/acpi: fix pcihp io initialization
> > >    hw/acpi: prepare pci hotplug IO for ich9
> > >    hw/acpi: extend acpi pci hotplug support for pci express
> > >    hw/ich9: enable acpi pci hotplug
> > > 
> > >   hw/acpi/ich9.c         |  31 +++++++++++++
> > >   hw/i386/acpi-build.c   | 116 ++++++++++++++++++++++++-------------------------
> > >   hw/isa/lpc_ich9.c      |  12 +++++
> > >   include/hw/acpi/ich9.h |   4 ++
> > >   include/hw/i386/pc.h   |   7 ++-
> > >   5 files changed, 111 insertions(+), 59 deletions(-)
> > > 
> > > -- 
> > > 2.7.4

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Igor Mammedov 6 years, 8 months ago
On Fri, 30 Jun 2017 10:25:05 +0300
Marcel Apfelbaum <marcel@redhat.com> wrote:

[...]
> 
> So for the modern systems not supporting PCI ACPI hotplug
> we don't need pci-bridges anyway, but for the older ones
> the ACPI code of the pci-bridge will be loaded into the
> ACPI namespace only if a pci-bridge is actually hot-plugged.

just note that the set of 'older' guest OSes is limited to
one that do not support SHPC (i.e. to EOLed WinXP & co)
as for linux and more modern Windows SHPC hotplug should
just work without our ACPI hack (which taxes low memory
to keep acpi tables for bridges).

So I'm in favor of Michael's suggestion to leave ACPI PCI
only in PC machine for old WinXP guests and to keep Q35
clean, where linux or newer Windows guests could just
use standard SHPC.

[...]

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Alexander Bezzubikov 6 years, 8 months ago
Hmm, I've failed to make SHPC (from current master) work on any modern
Linux guests.

2017-07-03 15:27 GMT+03:00 Igor Mammedov <imammedo@redhat.com>:

> On Fri, 30 Jun 2017 10:25:05 +0300
> Marcel Apfelbaum <marcel@redhat.com> wrote:
>
> [...]
> >
> > So for the modern systems not supporting PCI ACPI hotplug
> > we don't need pci-bridges anyway, but for the older ones
> > the ACPI code of the pci-bridge will be loaded into the
> > ACPI namespace only if a pci-bridge is actually hot-plugged.
>
> just note that the set of 'older' guest OSes is limited to
> one that do not support SHPC (i.e. to EOLed WinXP & co)
> as for linux and more modern Windows SHPC hotplug should
> just work without our ACPI hack (which taxes low memory
> to keep acpi tables for bridges).
>
> So I'm in favor of Michael's suggestion to leave ACPI PCI
> only in PC machine for old WinXP guests and to keep Q35
> clean, where linux or newer Windows guests could just
> use standard SHPC.
>
> [...]
>



-- 
Alexander Bezzubikov
Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Alexander Bezzubikov 6 years, 8 months ago
Do we have any surely working scenario of pci-bridge's SHPC usage? Because
first of all I've tried to use SHPC to avoi involving any ACPI code, but it
didn't look functioning even for ordinary pci-bridge, that's why after
talking to Marcel I left SHPC idea.

2017-07-03 16:58 GMT+03:00 Alexander Bezzubikov <zuban32s@gmail.com>:

> Hmm, I've failed to make SHPC (from current master) work on any modern
> Linux guests.
>
> 2017-07-03 15:27 GMT+03:00 Igor Mammedov <imammedo@redhat.com>:
>
>> On Fri, 30 Jun 2017 10:25:05 +0300
>> Marcel Apfelbaum <marcel@redhat.com> wrote:
>>
>> [...]
>> >
>> > So for the modern systems not supporting PCI ACPI hotplug
>> > we don't need pci-bridges anyway, but for the older ones
>> > the ACPI code of the pci-bridge will be loaded into the
>> > ACPI namespace only if a pci-bridge is actually hot-plugged.
>>
>> just note that the set of 'older' guest OSes is limited to
>> one that do not support SHPC (i.e. to EOLed WinXP & co)
>> as for linux and more modern Windows SHPC hotplug should
>> just work without our ACPI hack (which taxes low memory
>> to keep acpi tables for bridges).
>>
>> So I'm in favor of Michael's suggestion to leave ACPI PCI
>> only in PC machine for old WinXP guests and to keep Q35
>> clean, where linux or newer Windows guests could just
>> use standard SHPC.
>>
>> [...]
>>
>
>
>
> --
> Alexander Bezzubikov
>



-- 
Alexander Bezzubikov
Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Michael S. Tsirkin 6 years, 8 months ago
SHPC did work for linux. As ACPI is enabled by default, you need
to expose it in _OSC and maybe jump through more hoops
to avoid ACPI from trying to take over.

Source is available so if it doesn't work you should be able
to find out why.



On Mon, Jul 03, 2017 at 05:41:12PM +0300, Alexander Bezzubikov wrote:
> Do we have any surely working scenario of pci-bridge's SHPC usage? Because
> first of all I've tried to use SHPC to avoi involving any ACPI code, but it
> didn't look functioning even for ordinary pci-bridge, that's why after talking
> to Marcel I left SHPC idea.
> 
> 2017-07-03 16:58 GMT+03:00 Alexander Bezzubikov <zuban32s@gmail.com>:
> 
>     Hmm, I've failed to make SHPC (from current master) work on any modern
>     Linux guests.
> 
>     2017-07-03 15:27 GMT+03:00 Igor Mammedov <imammedo@redhat.com>:
> 
>         On Fri, 30 Jun 2017 10:25:05 +0300
>         Marcel Apfelbaum <marcel@redhat.com> wrote:
> 
>         [...]
>         >
>         > So for the modern systems not supporting PCI ACPI hotplug
>         > we don't need pci-bridges anyway, but for the older ones
>         > the ACPI code of the pci-bridge will be loaded into the
>         > ACPI namespace only if a pci-bridge is actually hot-plugged.
> 
>         just note that the set of 'older' guest OSes is limited to
>         one that do not support SHPC (i.e. to EOLed WinXP & co)
>         as for linux and more modern Windows SHPC hotplug should
>         just work without our ACPI hack (which taxes low memory
>         to keep acpi tables for bridges).
> 
>         So I'm in favor of Michael's suggestion to leave ACPI PCI
>         only in PC machine for old WinXP guests and to keep Q35
>         clean, where linux or newer Windows guests could just
>         use standard SHPC.
> 
>         [...]
> 
> 
> 
> 
>     --
>     Alexander Bezzubikov
> 
> 
> 
> 
> --
> Alexander Bezzubikov

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Michael S. Tsirkin 6 years, 8 months ago
On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
> On Fri, 30 Jun 2017 10:25:05 +0300
> Marcel Apfelbaum <marcel@redhat.com> wrote:
> 
> [...]
> > 
> > So for the modern systems not supporting PCI ACPI hotplug
> > we don't need pci-bridges anyway, but for the older ones
> > the ACPI code of the pci-bridge will be loaded into the
> > ACPI namespace only if a pci-bridge is actually hot-plugged.
> 
> just note that the set of 'older' guest OSes is limited to
> one that do not support SHPC (i.e. to EOLed WinXP & co)
> as for linux and more modern Windows SHPC hotplug should
> just work without our ACPI hack (which taxes low memory
> to keep acpi tables for bridges).
> 
> So I'm in favor of Michael's suggestion to leave ACPI PCI
> only in PC machine for old WinXP guests and to keep Q35
> clean, where linux or newer Windows guests could just
> use standard SHPC.
> 
> [...]

I didn't realize windows actually supports SHPC for PCI.

Do they correctly set _OSC Arg3, bit offset 1?
	SHPC Native Hot Plug control
	The OS sets this bit to 1 to request control over PCI/PCI-X Standard Hot-Plug Controller
	(SHPC) hot plug. If the OS successfully receives control of this feature, it must track and
	update the status of hot plug slots and handle hot plug events as described in the SHPC
	Specification.
I was under impression they only set bit 0.

-- 
MST

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Marcel Apfelbaum 6 years, 8 months ago
On 03/07/2017 19:34, Michael S. Tsirkin wrote:
> On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
>> On Fri, 30 Jun 2017 10:25:05 +0300
>> Marcel Apfelbaum <marcel@redhat.com> wrote:
>>
>> [...]
>>>
>>> So for the modern systems not supporting PCI ACPI hotplug
>>> we don't need pci-bridges anyway, but for the older ones
>>> the ACPI code of the pci-bridge will be loaded into the
>>> ACPI namespace only if a pci-bridge is actually hot-plugged.
>>
>> just note that the set of 'older' guest OSes is limited to
>> one that do not support SHPC (i.e. to EOLed WinXP & co)
>> as for linux and more modern Windows SHPC hotplug should
>> just work without our ACPI hack (which taxes low memory
>> to keep acpi tables for bridges).
>>
>> So I'm in favor of Michael's suggestion to leave ACPI PCI
>> only in PC machine for old WinXP guests and to keep Q35
>> clean, where linux or newer Windows guests could just
>> use standard SHPC.
>>
>> [...]
> 
> I didn't realize windows actually supports SHPC for PCI.

Me neither, if Igor is right I am all for shpc hotplug
since Q35 is not supposed to support older guests.

I remember I succeeded to enable shpc hotplug some time
ago, but only for Linux guests.

Igor, do you have some spec/doc on newer Windows OSes that confirm
PCI shpc hotplug support?

> 
> Do they correctly set _OSC Arg3, bit offset 1?
> 	SHPC Native Hot Plug control
> 	The OS sets this bit to 1 to request control over PCI/PCI-X Standard Hot-Plug Controller
> 	(SHPC) hot plug. If the OS successfully receives control of this feature, it must track and
> 	update the status of hot plug slots and handle hot plug events as described in the SHPC
> 	Specification.
> I was under impression they only set bit 0.
> 

Alexandr, if modern Windows OSes do support shpc, it makes our
job easier, can you please try to enable shpc hotplug?

Thanks,
Marcel

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Michael S. Tsirkin 6 years, 8 months ago
On Mon, Jul 03, 2017 at 09:26:33PM +0300, Marcel Apfelbaum wrote:
> On 03/07/2017 19:34, Michael S. Tsirkin wrote:
> > On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
> > > On Fri, 30 Jun 2017 10:25:05 +0300
> > > Marcel Apfelbaum <marcel@redhat.com> wrote:
> > > 
> > > [...]
> > > > 
> > > > So for the modern systems not supporting PCI ACPI hotplug
> > > > we don't need pci-bridges anyway, but for the older ones
> > > > the ACPI code of the pci-bridge will be loaded into the
> > > > ACPI namespace only if a pci-bridge is actually hot-plugged.
> > > 
> > > just note that the set of 'older' guest OSes is limited to
> > > one that do not support SHPC (i.e. to EOLed WinXP & co)
> > > as for linux and more modern Windows SHPC hotplug should
> > > just work without our ACPI hack (which taxes low memory
> > > to keep acpi tables for bridges).
> > > 
> > > So I'm in favor of Michael's suggestion to leave ACPI PCI
> > > only in PC machine for old WinXP guests and to keep Q35
> > > clean, where linux or newer Windows guests could just
> > > use standard SHPC.
> > > 
> > > [...]
> > 
> > I didn't realize windows actually supports SHPC for PCI.
> 
> Me neither, if Igor is right I am all for shpc hotplug
> since Q35 is not supposed to support older guests.
> 
> I remember I succeeded to enable shpc hotplug some time
> ago, but only for Linux guests.
> 
> Igor, do you have some spec/doc on newer Windows OSes that confirm
> PCI shpc hotplug support?

Just try it, easier than poking at specs which aren't always up to date.

> > 
> > Do they correctly set _OSC Arg3, bit offset 1?
> > 	SHPC Native Hot Plug control
> > 	The OS sets this bit to 1 to request control over PCI/PCI-X Standard Hot-Plug Controller
> > 	(SHPC) hot plug. If the OS successfully receives control of this feature, it must track and
> > 	update the status of hot plug slots and handle hot plug events as described in the SHPC
> > 	Specification.
> > I was under impression they only set bit 0.
> > 
> 
> Alexandr, if modern Windows OSes do support shpc, it makes our
> job easier, can you please try to enable shpc hotplug?
> 
> Thanks,
> Marcel

No need to enable or even have a bridge for that at all -
set the bit in _OSC, see what does guest enable.

Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Alexander Bezzubikov 6 years, 8 months ago
Tried it on Win7 Enterprise SP1 - SHPC works well,  _OSC patches aren't
necessary (since pci-bridge has its own controller, I suppose).
On Linux guests it works when adding device from CLI with -device, but OS
seems to fail detecting the device when I add it with device_add from
monitor.
Also there're some issues with unplugging on Linux (haven't tested
unplugging on WIndows yet). That's the news.

2017-07-03 21:29 GMT+03:00 Michael S. Tsirkin <mst@redhat.com>:

> On Mon, Jul 03, 2017 at 09:26:33PM +0300, Marcel Apfelbaum wrote:
> > On 03/07/2017 19:34, Michael S. Tsirkin wrote:
> > > On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
> > > > On Fri, 30 Jun 2017 10:25:05 +0300
> > > > Marcel Apfelbaum <marcel@redhat.com> wrote:
> > > >
> > > > [...]
> > > > >
> > > > > So for the modern systems not supporting PCI ACPI hotplug
> > > > > we don't need pci-bridges anyway, but for the older ones
> > > > > the ACPI code of the pci-bridge will be loaded into the
> > > > > ACPI namespace only if a pci-bridge is actually hot-plugged.
> > > >
> > > > just note that the set of 'older' guest OSes is limited to
> > > > one that do not support SHPC (i.e. to EOLed WinXP & co)
> > > > as for linux and more modern Windows SHPC hotplug should
> > > > just work without our ACPI hack (which taxes low memory
> > > > to keep acpi tables for bridges).
> > > >
> > > > So I'm in favor of Michael's suggestion to leave ACPI PCI
> > > > only in PC machine for old WinXP guests and to keep Q35
> > > > clean, where linux or newer Windows guests could just
> > > > use standard SHPC.
> > > >
> > > > [...]
> > >
> > > I didn't realize windows actually supports SHPC for PCI.
> >
> > Me neither, if Igor is right I am all for shpc hotplug
> > since Q35 is not supposed to support older guests.
> >
> > I remember I succeeded to enable shpc hotplug some time
> > ago, but only for Linux guests.
> >
> > Igor, do you have some spec/doc on newer Windows OSes that confirm
> > PCI shpc hotplug support?
>
> Just try it, easier than poking at specs which aren't always up to date.
>
> > >
> > > Do they correctly set _OSC Arg3, bit offset 1?
> > >     SHPC Native Hot Plug control
> > >     The OS sets this bit to 1 to request control over PCI/PCI-X
> Standard Hot-Plug Controller
> > >     (SHPC) hot plug. If the OS successfully receives control of this
> feature, it must track and
> > >     update the status of hot plug slots and handle hot plug events as
> described in the SHPC
> > >     Specification.
> > > I was under impression they only set bit 0.
> > >
> >
> > Alexandr, if modern Windows OSes do support shpc, it makes our
> > job easier, can you please try to enable shpc hotplug?
> >
> > Thanks,
> > Marcel
>
> No need to enable or even have a bridge for that at all -
> set the bit in _OSC, see what does guest enable.
>



-- 
Alexander Bezzubikov
Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Alexander Bezzubikov 6 years, 8 months ago
That is why I think we can consider a possibility of forgetting about ACPI
hot plug in pcie-pci bridge and use only SHPC (with some correcting work).
Especially since q35 is used only for 'modern' Windows guests and there're
no big problems with SHPC on Linux guests.

вт, 4 июля 2017 г. в 1:06, Alexander Bezzubikov <zuban32s@gmail.com>:

> Tried it on Win7 Enterprise SP1 - SHPC works well,  _OSC patches aren't
> necessary (since pci-bridge has its own controller, I suppose).
> On Linux guests it works when adding device from CLI with -device, but OS
> seems to fail detecting the device when I add it with device_add from
> monitor.
> Also there're some issues with unplugging on Linux (haven't tested
> unplugging on WIndows yet). That's the news.
>
> 2017-07-03 21:29 GMT+03:00 Michael S. Tsirkin <mst@redhat.com>:
>
>> On Mon, Jul 03, 2017 at 09:26:33PM +0300, Marcel Apfelbaum wrote:
>> > On 03/07/2017 19:34, Michael S. Tsirkin wrote:
>> > > On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
>> > > > On Fri, 30 Jun 2017 10:25:05 +0300
>> > > > Marcel Apfelbaum <marcel@redhat.com> wrote:
>> > > >
>> > > > [...]
>> > > > >
>> > > > > So for the modern systems not supporting PCI ACPI hotplug
>> > > > > we don't need pci-bridges anyway, but for the older ones
>> > > > > the ACPI code of the pci-bridge will be loaded into the
>> > > > > ACPI namespace only if a pci-bridge is actually hot-plugged.
>> > > >
>> > > > just note that the set of 'older' guest OSes is limited to
>> > > > one that do not support SHPC (i.e. to EOLed WinXP & co)
>> > > > as for linux and more modern Windows SHPC hotplug should
>> > > > just work without our ACPI hack (which taxes low memory
>> > > > to keep acpi tables for bridges).
>> > > >
>> > > > So I'm in favor of Michael's suggestion to leave ACPI PCI
>> > > > only in PC machine for old WinXP guests and to keep Q35
>> > > > clean, where linux or newer Windows guests could just
>> > > > use standard SHPC.
>> > > >
>> > > > [...]
>> > >
>> > > I didn't realize windows actually supports SHPC for PCI.
>> >
>> > Me neither, if Igor is right I am all for shpc hotplug
>> > since Q35 is not supposed to support older guests.
>> >
>> > I remember I succeeded to enable shpc hotplug some time
>> > ago, but only for Linux guests.
>> >
>> > Igor, do you have some spec/doc on newer Windows OSes that confirm
>> > PCI shpc hotplug support?
>>
>> Just try it, easier than poking at specs which aren't always up to date.
>>
>> > >
>> > > Do they correctly set _OSC Arg3, bit offset 1?
>> > >     SHPC Native Hot Plug control
>> > >     The OS sets this bit to 1 to request control over PCI/PCI-X
>> Standard Hot-Plug Controller
>> > >     (SHPC) hot plug. If the OS successfully receives control of this
>> feature, it must track and
>> > >     update the status of hot plug slots and handle hot plug events as
>> described in the SHPC
>> > >     Specification.
>> > > I was under impression they only set bit 0.
>> > >
>> >
>> > Alexandr, if modern Windows OSes do support shpc, it makes our
>> > job easier, can you please try to enable shpc hotplug?
>> >
>> > Thanks,
>> > Marcel
>>
>> No need to enable or even have a bridge for that at all -
>> set the bit in _OSC, see what does guest enable.
>>
>
>
>
> --
> Alexander Bezzubikov
>
-- 
Alexander Bezzubikov
Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Marcel Apfelbaum 6 years, 8 months ago
On 04/07/2017 4:00, Alexander Bezzubikov wrote:
> That is why I think we can consider a possibility of forgetting about 
> ACPI hot plug in pcie-pci bridge and use only SHPC (with some correcting 
> work). Especially since q35 is used only for 'modern' Windows guests and 
> there're no big problems with SHPC on Linux guests.

Hi Alexandr,

Sure, SHPC is certainly enough, and Windows7+ guests support
is also enough.
Patches for a hot-pluggable pcie-pci bridge supporting SHPC based
hot-plug/hot-unplug are welcome :) .

One last thing, please avoid top-posting...

Thanks,
Marcel

> 
> вт, 4 июля 2017 г. в 1:06, Alexander Bezzubikov <zuban32s@gmail.com 
> <mailto:zuban32s@gmail.com>>:
> 
>     Tried it on Win7 Enterprise SP1 - SHPC works well,  _OSC patches
>     aren't necessary (since pci-bridge has its own controller, I suppose).
>     On Linux guests it works when adding device from CLI with -device,
>     but OS seems to fail detecting the device when I add it with
>     device_add from monitor.
>     Also there're some issues with unplugging on Linux (haven't tested
>     unplugging on WIndows yet). That's the news.
> 
>     2017-07-03 21:29 GMT+03:00 Michael S. Tsirkin <mst@redhat.com
>     <mailto:mst@redhat.com>>:
> 
>         On Mon, Jul 03, 2017 at 09:26:33PM +0300, Marcel Apfelbaum wrote:
>          > On 03/07/2017 19:34, Michael S. Tsirkin wrote:
>          > > On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
>          > > > On Fri, 30 Jun 2017 10:25:05 +0300
>          > > > Marcel Apfelbaum <marcel@redhat.com
>         <mailto:marcel@redhat.com>> wrote:
>          > > >
>          > > > [...]
>          > > > >
>          > > > > So for the modern systems not supporting PCI ACPI hotplug
>          > > > > we don't need pci-bridges anyway, but for the older ones
>          > > > > the ACPI code of the pci-bridge will be loaded into the
>          > > > > ACPI namespace only if a pci-bridge is actually
>         hot-plugged.
>          > > >
>          > > > just note that the set of 'older' guest OSes is limited to
>          > > > one that do not support SHPC (i.e. to EOLed WinXP & co)
>          > > > as for linux and more modern Windows SHPC hotplug should
>          > > > just work without our ACPI hack (which taxes low memory
>          > > > to keep acpi tables for bridges).
>          > > >
>          > > > So I'm in favor of Michael's suggestion to leave ACPI PCI
>          > > > only in PC machine for old WinXP guests and to keep Q35
>          > > > clean, where linux or newer Windows guests could just
>          > > > use standard SHPC.
>          > > >
>          > > > [...]
>          > >
>          > > I didn't realize windows actually supports SHPC for PCI.
>          >
>          > Me neither, if Igor is right I am all for shpc hotplug
>          > since Q35 is not supposed to support older guests.
>          >
>          > I remember I succeeded to enable shpc hotplug some time
>          > ago, but only for Linux guests.
>          >
>          > Igor, do you have some spec/doc on newer Windows OSes that
>         confirm
>          > PCI shpc hotplug support?
> 
>         Just try it, easier than poking at specs which aren't always up
>         to date.
> 
>         > >
>         > > Do they correctly set _OSC Arg3, bit offset 1?
>         > >     SHPC Native Hot Plug control
>         > >     The OS sets this bit to 1 to request control over PCI/PCI-X Standard Hot-Plug Controller
>         > >     (SHPC) hot plug. If the OS successfully receives control of this feature, it must track and
>         > >     update the status of hot plug slots and handle hot plug events as described in the SHPC
>         > >     Specification.
>         > > I was under impression they only set bit 0.
>         > >
>         >
>         > Alexandr, if modern Windows OSes do support shpc, it makes our
>         > job easier, can you please try to enable shpc hotplug?
>         >
>         > Thanks,
>         > Marcel
> 
>         No need to enable or even have a bridge for that at all -
>         set the bit in _OSC, see what does guest enable.
> 
> 
> 
> 
>     -- 
>     Alexander Bezzubikov
> 
> -- 
> Alexander Bezzubikov


Re: [Qemu-devel] [PATCH RFC 0/6] q35: add acpi pci hotplug support
Posted by Igor Mammedov 6 years, 8 months ago
On Mon, 3 Jul 2017 19:34:07 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Jul 03, 2017 at 02:27:11PM +0200, Igor Mammedov wrote:
> > On Fri, 30 Jun 2017 10:25:05 +0300
> > Marcel Apfelbaum <marcel@redhat.com> wrote:
> > 
> > [...]  
> > > 
> > > So for the modern systems not supporting PCI ACPI hotplug
> > > we don't need pci-bridges anyway, but for the older ones
> > > the ACPI code of the pci-bridge will be loaded into the
> > > ACPI namespace only if a pci-bridge is actually hot-plugged.  
> > 
> > just note that the set of 'older' guest OSes is limited to
> > one that do not support SHPC (i.e. to EOLed WinXP & co)
> > as for linux and more modern Windows SHPC hotplug should
> > just work without our ACPI hack (which taxes low memory
> > to keep acpi tables for bridges).
> > 
> > So I'm in favor of Michael's suggestion to leave ACPI PCI
> > only in PC machine for old WinXP guests and to keep Q35
> > clean, where linux or newer Windows guests could just
> > use standard SHPC.
> > 
> > [...]  
> 
> I didn't realize windows actually supports SHPC for PCI.
> 
> Do they correctly set _OSC Arg3, bit offset 1?
> 	SHPC Native Hot Plug control
> 	The OS sets this bit to 1 to request control over PCI/PCI-X Standard Hot-Plug Controller
> 	(SHPC) hot plug. If the OS successfully receives control of this feature, it must track and
> 	update the status of hot plug slots and handle hot plug events as described in the SHPC
> 	Specification.
> I was under impression they only set bit 0.

Alexander,

wrt windows it might be worth to keep in mind
  https://msdn.microsoft.com/en-us/library/windows/hardware/dn631753(v=vs.85).aspx

as for QEMU,
one should remove masking SHPC support in QEMU ACPI part
 build_q35_osc_method()

hw switch to SHPC method happens for bridges in shpc_init() see qbus_set_hotplug_handler()