>>> On 4/27/2017 at 12:08 PM, Stefano Stabellini <sstabell...@kernel.org> >>> wrote: > On Thu, 27 Apr 2017, Igor Mammedov wrote: >> On Thu, 27 Apr 2017 10:51:23 -0600 >> "Bruce Rogers" <brog...@suse.com> wrote: >> >> > >> > >> > >>> On 4/27/2017 at 10:08 AM, Igor Mammedov <imamm...@redhat.com> wrote: >> > > On Thu, 27 Apr 2017 09:44:31 -0600 >> > > "Bruce Rogers" <brog...@suse.com> wrote: >> > > >> > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imamm...@redhat.com> >> > >> >>> wrote: >> > >> > On Wed, 26 Apr 2017 13:07:02 -0600 >> > >> > Bruce Rogers <brog...@suse.com> wrote: >> > >> > >> > >> >> Commit f0c9d64a exposed an issue with the code order in acpi_setup. >> > >> >> As of that commit, a xenfv machine type guest will no longer start >> > >> >> if using pci passthrough. Re-order the code in that function to >> > >> >> allow acpi_set_pci_info to be called before bailing on the other, >> > >> >> non-related conditions. With this change I can again use pci >> > >> >> passthrough and xenfv together. >> > >> >> >> > >> >> Signed-off-by: Bruce Rogers <brog...@suse.com> >> > >> > it doesn't look right, >> > >> > acpi_set_pci_info() is supposed to affect only ACPI based hotplug >> > >> > >> > >> > could you elaborate more on what's going on and >> > >> > what error you see at startup? >> > >> >> > >> I am using libvirt, driving the creation of the Xen HVM guest via >> > >> libxl. libxl dynamically attaches the pci device via QMP. In the >> > >> context of qmp_device_add(), we get a failure in hw/acpi/pcihp.c: >> > >> acpi_pcihp_device_plug_cb() when it checks for bsel, and errors >> > >> with the message: "Unsupported bus. Bus doesn't have property >> > >> 'acpi-pcihp-bsel' set". I guess it wasn't clear from my description >> > >> that hotplug was involved. >> > >> >> > > is dev->hotplugged in acpi_pcihp_device_plug_cb() true at that time? >> > > >> > > the point is that bsel is needed only when there is supporting ACPI code >> > > and useless otherwise, so acpi_pcihp_device_plug_cb() probably shouldn't >> > > run under xenfv. I'd try to add compat prop to PIIX4_PM and disable >> > > acpi_pcihp_device_plug_cb() for xenfv via machine compat property. >> > >> > So what would be wrong with simply conditionalizing the call to >> > acpi_pcihp_device_plug_cb() with a check for xen in piix4_device_plug_cb() >> > as follows: >> > >> > } >> > } else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) { >> > - acpi_pcihp_device_plug_cb(hotplug_dev, &s->acpi_pci_hotplug, dev, > errp); >> > + if (!xen_enabled()) { >> > + acpi_pcihp_device_plug_cb(hotplug_dev, &s->acpi_pci_hotplug, >> > dev, >> > + errp); >> > + } >> > } else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) { >> > if (s->cpu_hotplug_legacy) { >> > legacy_acpi_cpu_plug_cb(hotplug_dev, &s->gpe_cpu, dev, errp); >> > >> > Wouldn't that be the solution? >> it should work >> >> is it possible to see unplug on that device later under xen? > > Yes, it would be possible. I guess we need to do the same for > acpi_pcihp_device_unplug_cb?
Thanks guys, I'll send a new patch based on this discussion. Bruce