| Message ID | 1493233622-14485-1-git-send-email-brogers@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 26 Apr 2017 13:07:02 -0600 Bruce Rogers <brogers@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 <brogers@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? > --- > hw/i386/acpi-build.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index 2073108..1ec072f 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -2834,6 +2834,13 @@ void acpi_setup(void) > AcpiBuildState *build_state; > Object *vmgenid_dev; > > + if (!acpi_enabled) { > + ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); > + return; > + } > + > + acpi_set_pci_info(); > + > if (!pcms->fw_cfg) { > ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n"); > return; > @@ -2844,15 +2851,8 @@ void acpi_setup(void) > return; > } > > - if (!acpi_enabled) { > - ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); > - return; > - } > - > build_state = g_malloc0(sizeof *build_state); > > - acpi_set_pci_info(); > - > acpi_build_tables_init(&tables); > acpi_build(&tables, MACHINE(pcms)); >
>>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: > On Wed, 26 Apr 2017 13:07:02 -0600 > Bruce Rogers <brogers@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 <brogers@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. Bruce > >> --- >> hw/i386/acpi-build.c | 14 +++++++------- >> 1 file changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c >> index 2073108..1ec072f 100644 >> --- a/hw/i386/acpi-build.c >> +++ b/hw/i386/acpi-build.c >> @@ -2834,6 +2834,13 @@ void acpi_setup(void) >> AcpiBuildState *build_state; >> Object *vmgenid_dev; >> >> + if (!acpi_enabled) { >> + ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); >> + return; >> + } >> + >> + acpi_set_pci_info(); >> + >> if (!pcms->fw_cfg) { >> ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n"); >> return; >> @@ -2844,15 +2851,8 @@ void acpi_setup(void) >> return; >> } >> >> - if (!acpi_enabled) { >> - ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); >> - return; >> - } >> - >> build_state = g_malloc0(sizeof *build_state); >> >> - acpi_set_pci_info(); >> - >> acpi_build_tables_init(&tables); >> acpi_build(&tables, MACHINE(pcms)); >>
On Thu, 27 Apr 2017 09:44:31 -0600 "Bruce Rogers" <brogers@suse.com> wrote: > >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: > > On Wed, 26 Apr 2017 13:07:02 -0600 > > Bruce Rogers <brogers@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 <brogers@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. > Bruce > > > > >> --- > >> hw/i386/acpi-build.c | 14 +++++++------- > >> 1 file changed, 7 insertions(+), 7 deletions(-) > >> > >> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > >> index 2073108..1ec072f 100644 > >> --- a/hw/i386/acpi-build.c > >> +++ b/hw/i386/acpi-build.c > >> @@ -2834,6 +2834,13 @@ void acpi_setup(void) > >> AcpiBuildState *build_state; > >> Object *vmgenid_dev; > >> > >> + if (!acpi_enabled) { > >> + ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); > >> + return; > >> + } > >> + > >> + acpi_set_pci_info(); > >> + > >> if (!pcms->fw_cfg) { > >> ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n"); > >> return; > >> @@ -2844,15 +2851,8 @@ void acpi_setup(void) > >> return; > >> } > >> > >> - if (!acpi_enabled) { > >> - ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); > >> - return; > >> - } > >> - > >> build_state = g_malloc0(sizeof *build_state); > >> > >> - acpi_set_pci_info(); > >> - > >> acpi_build_tables_init(&tables); > >> acpi_build(&tables, MACHINE(pcms)); > >> > >
>>> On 4/27/2017 at 10:08 AM, Igor Mammedov <imammedo@redhat.com> wrote: > On Thu, 27 Apr 2017 09:44:31 -0600 > "Bruce Rogers" <brogers@suse.com> wrote: > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: >> > On Wed, 26 Apr 2017 13:07:02 -0600 >> > Bruce Rogers <brogers@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 <brogers@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? Yes it is. It gets set in hw/core/qdev.c:device_initfn(). > > 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. I'll look into this then. I'm not too familiar yet with this area of the code. I simply bisected the problem, which pointed to the commit id referenced in the patch, and came up with what seemed like the most obvious solution. > >> Bruce >> >> > >> >> --- >> >> hw/i386/acpi-build.c | 14 +++++++------- >> >> 1 file changed, 7 insertions(+), 7 deletions(-) >> >> >> >> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c >> >> index 2073108..1ec072f 100644 >> >> --- a/hw/i386/acpi-build.c >> >> +++ b/hw/i386/acpi-build.c >> >> @@ -2834,6 +2834,13 @@ void acpi_setup(void) >> >> AcpiBuildState *build_state; >> >> Object *vmgenid_dev; >> >> >> >> + if (!acpi_enabled) { >> >> + ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); >> >> + return; >> >> + } >> >> + >> >> + acpi_set_pci_info(); >> >> + >> >> if (!pcms->fw_cfg) { >> >> ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n"); >> >> return; >> >> @@ -2844,15 +2851,8 @@ void acpi_setup(void) >> >> return; >> >> } >> >> >> >> - if (!acpi_enabled) { >> >> - ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); >> >> - return; >> >> - } >> >> - >> >> build_state = g_malloc0(sizeof *build_state); >> >> >> >> - acpi_set_pci_info(); >> >> - >> >> acpi_build_tables_init(&tables); >> >> acpi_build(&tables, MACHINE(pcms)); >> >> >> >>
>>> On 4/27/2017 at 10:08 AM, Igor Mammedov <imammedo@redhat.com> wrote: > On Thu, 27 Apr 2017 09:44:31 -0600 > "Bruce Rogers" <brogers@suse.com> wrote: > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: >> > On Wed, 26 Apr 2017 13:07:02 -0600 >> > Bruce Rogers <brogers@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 <brogers@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? Bruce
On Thu, 27 Apr 2017 10:51:23 -0600 "Bruce Rogers" <brogers@suse.com> wrote: > > > >>> On 4/27/2017 at 10:08 AM, Igor Mammedov <imammedo@redhat.com> wrote: > > On Thu, 27 Apr 2017 09:44:31 -0600 > > "Bruce Rogers" <brogers@suse.com> wrote: > > > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: > >> > On Wed, 26 Apr 2017 13:07:02 -0600 > >> > Bruce Rogers <brogers@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 <brogers@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? > > Bruce > >
On Thu, 27 Apr 2017, Igor Mammedov wrote: > On Thu, 27 Apr 2017 10:51:23 -0600 > "Bruce Rogers" <brogers@suse.com> wrote: > > > > > > > >>> On 4/27/2017 at 10:08 AM, Igor Mammedov <imammedo@redhat.com> wrote: > > > On Thu, 27 Apr 2017 09:44:31 -0600 > > > "Bruce Rogers" <brogers@suse.com> wrote: > > > > > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: > > >> > On Wed, 26 Apr 2017 13:07:02 -0600 > > >> > Bruce Rogers <brogers@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 <brogers@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?
>>> On 4/27/2017 at 12:08 PM, Stefano Stabellini <sstabellini@kernel.org> wrote: > On Thu, 27 Apr 2017, Igor Mammedov wrote: >> On Thu, 27 Apr 2017 10:51:23 -0600 >> "Bruce Rogers" <brogers@suse.com> wrote: >> >> > >> > >> > >>> On 4/27/2017 at 10:08 AM, Igor Mammedov <imammedo@redhat.com> wrote: >> > > On Thu, 27 Apr 2017 09:44:31 -0600 >> > > "Bruce Rogers" <brogers@suse.com> wrote: >> > > >> > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <imammedo@redhat.com> wrote: >> > >> > On Wed, 26 Apr 2017 13:07:02 -0600 >> > >> > Bruce Rogers <brogers@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 <brogers@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
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index 2073108..1ec072f 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -2834,6 +2834,13 @@ void acpi_setup(void) AcpiBuildState *build_state; Object *vmgenid_dev; + if (!acpi_enabled) { + ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); + return; + } + + acpi_set_pci_info(); + if (!pcms->fw_cfg) { ACPI_BUILD_DPRINTF("No fw cfg. Bailing out.\n"); return; @@ -2844,15 +2851,8 @@ void acpi_setup(void) return; } - if (!acpi_enabled) { - ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n"); - return; - } - build_state = g_malloc0(sizeof *build_state); - acpi_set_pci_info(); - acpi_build_tables_init(&tables); acpi_build(&tables, MACHINE(pcms));
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 <brogers@suse.com> --- hw/i386/acpi-build.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)