On Mon, 3 Jul 2017 19:34:07 +0300 "Michael S. Tsirkin" <m...@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 <mar...@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()