On Thu, Oct 1, 2020 at 9:24 PM Julia Suvorova <jus...@redhat.com> wrote:
> On Thu, Oct 1, 2020 at 1:40 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > > > > > On Thu, Oct 01, 2020 at 10:55:35AM +0200, Julia Suvorova wrote: > > > > On Thu, Sep 24, 2020 at 11:20 AM Michael S. Tsirkin <m...@redhat.com> > wrote: > > > > > > > > > > On Thu, Sep 24, 2020 at 09:00:06AM +0200, Julia Suvorova wrote: > > > > > > The patch set consists of two parts: > > > > > > patches 1-4: introduce new feature > > > > > > 'acpi-pci-hotplug-with-bridge-support' on Q35 > > > > > > patches 5-7: make the feature default along with changes in ACPI > tables > > > > > > > > > > > > This way maintainers can decide which way to choose without > breaking > > > > > > the patch set. > > > > > > > > > > > > With the feature disabled Q35 falls back to the native hot-plug. > > > > > > > > > > > > Pros > > > > > > * no racy behavior during boot (see 110c477c2ed) > > > > > > * eject is possible - according to PCIe spec, attention button > > > > > > press should lead to power off, and then the adapter should > be > > > > > > removed manually. As there is no power down state exists in > QEMU, > > > > > > we cannot distinguish between an eject and a power down > > > > > > request. > > > > > > * no delay during deleting - after the actual power off > software > > > > > > must wait at least 1 second before indicating about it. This > case > > > > > > is quite important for users, it even has its own bug: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1594168 > > > > > > * no timer-based behavior - in addition to the previous > example, > > > > > > the attention button has a 5-second waiting period, during > which > > > > > > the operation can be canceled with a second press. While this > > > > > > looks fine for manual button control, automation will result > in > > > > > > the need to queue or drop events, and the software receiving > > > > > > events in all sort of unspecified combinations of > attention/power > > > > > > indicator states, which is racy and uppredictable. > > > > > > * fixes: > > > > > > * https://bugzilla.redhat.com/show_bug.cgi?id=1752465 > > > > > > * https://bugzilla.redhat.com/show_bug.cgi?id=1690256 > > > > > > > > > > > > Cons: > > > > > > * lose per-port control over hot-plug (can be resolved) > > > > > > * no access to possible features presented in slot capabilities > > > > > > (this is only surprise removal AFAIK) > > > > > > > > > > something I don't quite get is whether with this one can still add > > > > > new pcie bridges and then hotplug into these with native > > > > > hotplug. > > > > > > > > Right now I disable native if there is acpihp anywhere, but even if > > > > you enable it for hotplugged devices, native hot-plug will not work. > > > > > > So that's a minor regression in functionality, right? > > > Why is that the case? Because you disable it in ACPI? > > > What if we don't? > > > > I meant that I disable slot hotplug capabilities, nothing in ACPI > > prevents native from working. Actually, I don't see if there's any > > regression at all. Configurations like hot-plugging downstream port or > > switch to another downstream port haven't worked before, and they > > don't work now. I can enable native for hotplugged bridges, but that > > doesn't make sense, because you won't be able to hot-plug anything to > > it. Why is that? It's not an issue of ACPI, it's PCIe behaviour. Also, native-acpi > > combination may seem bizarre to os (slot enumeration is independent, > > that's why I suggested disabling pcie slot flags). > > > > > > > the challenge to answering this with certainty is that right now qemu > > > > > does not allow hotplugging complex devices such as bridges at all, > > > > > we only have a hack for multifunction devices. > > > > > Maybe adding a bridge as function 1 on command line, then > hotplugging another device as > > > > > function 0 will work to test this. > > > > > > > > > > > > > > > > > > > > > v3: > > > > > > * drop change of _OSC to allow SHPC on hotplugged bridges > > > > > > * use 'acpi-root-pci-hotplug' > > > > > > * add migration states [Igor] > > > > > > * minor style changes > > > > > > > > > > > > v2: > > > > > > * new ioport range for acpiphp [Gerd] > > > > > > * drop find_pci_host() [Igor] > > > > > > * explain magic numbers in _OSC [Igor] > > > > > > * drop build_q35_pci_hotplug() wrapper [Igor] > > > > > > > > > > > > Julia Suvorova (7): > > > > > > hw/acpi/pcihp: Enhance acpi_pcihp_disable_root_bus() to support > Q35 > > > > > > hw/i386/acpi-build: Add ACPI PCI hot-plug methods to Q35 > > > > > > hw/pci/pcie: Do not initialize slot capability if acpihp is used > > > > > > hw/acpi/ich9: Enable ACPI PCI hot-plug > > > > > > bios-tables-test: Allow changes in DSDT ACPI tables > > > > > > hw/acpi/ich9: Set ACPI PCI hot-plug as default > > > > > > bios-tables-test: Update golden binaries > > > > > > > > > > > > hw/i386/acpi-build.h | 7 ++++ > > > > > > include/hw/acpi/ich9.h | 5 +++ > > > > > > include/hw/acpi/pcihp.h | 3 +- > > > > > > hw/acpi/ich9.c | 67 > ++++++++++++++++++++++++++++++ > > > > > > hw/acpi/pcihp.c | 16 ++++--- > > > > > > hw/acpi/piix4.c | 4 +- > > > > > > hw/i386/acpi-build.c | 31 ++++++++------ > > > > > > hw/i386/pc.c | 1 + > > > > > > hw/pci/pcie.c | 16 +++++++ > > > > > > tests/data/acpi/q35/DSDT | Bin 7678 -> 7950 bytes > > > > > > tests/data/acpi/q35/DSDT.acpihmat | Bin 9002 -> 9274 bytes > > > > > > tests/data/acpi/q35/DSDT.bridge | Bin 7695 -> 9865 bytes > > > > > > tests/data/acpi/q35/DSDT.cphp | Bin 8141 -> 8413 bytes > > > > > > tests/data/acpi/q35/DSDT.dimmpxm | Bin 9331 -> 9603 bytes > > > > > > tests/data/acpi/q35/DSDT.ipmibt | Bin 7753 -> 8025 bytes > > > > > > tests/data/acpi/q35/DSDT.memhp | Bin 9037 -> 9309 bytes > > > > > > tests/data/acpi/q35/DSDT.mmio64 | Bin 8808 -> 9080 bytes > > > > > > tests/data/acpi/q35/DSDT.numamem | Bin 7684 -> 7956 bytes > > > > > > tests/data/acpi/q35/DSDT.tis | Bin 8283 -> 8555 bytes > > > > > > 19 files changed, 129 insertions(+), 21 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.25.4 > > > > > > > > > > > >
