* [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
@ 2017-04-26 19:07 Bruce Rogers
2017-04-27 9:11 ` Igor Mammedov
0 siblings, 1 reply; 9+ messages in thread
From: Bruce Rogers @ 2017-04-26 19:07 UTC (permalink / raw)
To: qemu-devel; +Cc: imammedo, sstabellini, mst, qemu-stable, Bruce Rogers
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(-)
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));
--
1.9.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-26 19:07 [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled Bruce Rogers
@ 2017-04-27 9:11 ` Igor Mammedov
2017-04-27 15:44 ` Bruce Rogers
0 siblings, 1 reply; 9+ messages in thread
From: Igor Mammedov @ 2017-04-27 9:11 UTC (permalink / raw)
To: Bruce Rogers; +Cc: qemu-devel, sstabellini, mst, qemu-stable
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));
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 9:11 ` Igor Mammedov
@ 2017-04-27 15:44 ` Bruce Rogers
2017-04-27 16:08 ` Igor Mammedov
0 siblings, 1 reply; 9+ messages in thread
From: Bruce Rogers @ 2017-04-27 15:44 UTC (permalink / raw)
To: Igor Mammedov; +Cc: sstabellini, qemu-devel, qemu-stable, mst
>>> 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));
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 15:44 ` Bruce Rogers
@ 2017-04-27 16:08 ` Igor Mammedov
2017-04-27 16:29 ` Bruce Rogers
2017-04-27 16:51 ` Bruce Rogers
0 siblings, 2 replies; 9+ messages in thread
From: Igor Mammedov @ 2017-04-27 16:08 UTC (permalink / raw)
To: Bruce Rogers; +Cc: sstabellini, qemu-devel, qemu-stable, mst
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));
> >>
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 16:08 ` Igor Mammedov
@ 2017-04-27 16:29 ` Bruce Rogers
2017-04-27 16:51 ` Bruce Rogers
1 sibling, 0 replies; 9+ messages in thread
From: Bruce Rogers @ 2017-04-27 16:29 UTC (permalink / raw)
To: Igor Mammedov; +Cc: sstabellini, qemu-devel, qemu-stable, mst
>>> 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));
>> >>
>>
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 16:08 ` Igor Mammedov
2017-04-27 16:29 ` Bruce Rogers
@ 2017-04-27 16:51 ` Bruce Rogers
2017-04-27 17:35 ` Igor Mammedov
1 sibling, 1 reply; 9+ messages in thread
From: Bruce Rogers @ 2017-04-27 16:51 UTC (permalink / raw)
To: Igor Mammedov; +Cc: sstabellini, qemu-devel, qemu-stable, mst
>>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 16:51 ` Bruce Rogers
@ 2017-04-27 17:35 ` Igor Mammedov
2017-04-27 18:08 ` Stefano Stabellini
0 siblings, 1 reply; 9+ messages in thread
From: Igor Mammedov @ 2017-04-27 17:35 UTC (permalink / raw)
To: Bruce Rogers; +Cc: sstabellini, mst, qemu-devel, qemu-stable
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
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 17:35 ` Igor Mammedov
@ 2017-04-27 18:08 ` Stefano Stabellini
2017-04-27 19:57 ` Bruce Rogers
0 siblings, 1 reply; 9+ messages in thread
From: Stefano Stabellini @ 2017-04-27 18:08 UTC (permalink / raw)
To: Igor Mammedov; +Cc: Bruce Rogers, sstabellini, mst, qemu-devel, qemu-stable
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled
2017-04-27 18:08 ` Stefano Stabellini
@ 2017-04-27 19:57 ` Bruce Rogers
0 siblings, 0 replies; 9+ messages in thread
From: Bruce Rogers @ 2017-04-27 19:57 UTC (permalink / raw)
To: Stefano Stabellini, Igor Mammedov; +Cc: qemu-devel, qemu-stable, mst
>>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-04-27 19:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-26 19:07 [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled Bruce Rogers
2017-04-27 9:11 ` Igor Mammedov
2017-04-27 15:44 ` Bruce Rogers
2017-04-27 16:08 ` Igor Mammedov
2017-04-27 16:29 ` Bruce Rogers
2017-04-27 16:51 ` Bruce Rogers
2017-04-27 17:35 ` Igor Mammedov
2017-04-27 18:08 ` Stefano Stabellini
2017-04-27 19:57 ` Bruce Rogers
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.