On Thu, Nov 11, 2021 at 03:20:07AM -0500, Michael S. Tsirkin wrote: > On Thu, Nov 11, 2021 at 08:53:06AM +0100, Gerd Hoffmann wrote: > > Hi, > > > > > Given it's a bugfix, and given that I hear through internal channels > > > that QE results so far have been encouraging, I am inclined to bite the > > > bullet and merge this for -rc1. > > > > Fine with me. > > > > > I don't think this conflicts with Julia's patches as users can still > > > disable ACPI hotplug into bridges. Gerd, agree? Worth the risk? > > > > Combining this with Julia's patches looks a bit risky to me and surely > > needs testing. I expect the problematic case is both native and acpi > > hotplug being enabled. > > When the guest uses acpi hotplug nobody will > > turn on slot power on the pcie root port ... > > I'm not sure I understand what the situation is, and how to trigger it. > Could you clarify pls?
My patch series implements proper slot power emulation for pcie root ports, i.e. the pci device plugged into the slot is only visible to the guest when slot power is enabled. When the pciehp driver is used the linux kernel will enable slot power of course. When the acpihp driver is used the linux kernel will just call the aml methods and I suspect the pci device will stay invisible then because nobody flips the slot power control bit (with native-hotplug=on, for native-hotplug=off this isn't a problem of course). > > I'd suggest to just revert to pcie native hotplug for 6.2. > > Hmm that kind of change seems even riskier to me. It's not clear to me why you consider that riskier. It should fix the qemu 6.1 regressions. Given QE has found no problems so far it should not be worse than qemu 6.0 was. Most likely it will work better than qemu 6.0. Going with a new approach (enable both native and acpi hotplug) after freeze looks risky to me, even without considering the conflict outlined above. Last-minute changes with the chance to repeat the 6.1 disaster, only with a different set of bugs ... take care, Gerd
