Re: [Qemu-stable] [Qemu-devel] [PATCH] ACPI: call acpi_set_pci_info when only acpi enabled

[Bruce Rogers]

>>> On 4/27/2017 at 12:08 PM, Stefano Stabellini <address@hidden> wrote: 
> On Thu, 27 Apr 2017, Igor Mammedov wrote:
>> On Thu, 27 Apr 2017 10:51:23 -0600
>> "Bruce Rogers" <address@hidden> wrote:
>> 
>> > 
>> > 
>> > >>> On 4/27/2017 at 10:08 AM, Igor Mammedov <address@hidden> wrote: 
>> > > On Thu, 27 Apr 2017 09:44:31 -0600
>> > > "Bruce Rogers" <address@hidden> wrote:
>> > > 
>> > >> >>> On 4/27/2017 at 03:11 AM, Igor Mammedov <address@hidden> wrote: 
>> > >> > On Wed, 26 Apr 2017 13:07:02 -0600
>> > >> > Bruce Rogers <address@hidden> 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 <address@hidden>
>> > >> > 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