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(-)
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
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
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
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
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. [...]
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
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
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
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
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
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.
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
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
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
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()
© 2016 - 2024 Red Hat, Inc.