Re: [PATCH v7 09/36] hw/pci-host/gpex-acpi: Use build_pci_host_bridge_osc_method

[Eric Auger <eric.auger@redhat.com>]

Hi Michael,
On 7/28/25 5:17 PM, Michael Tokarev wrote:
> On 28.07.2025 17:56, Eric Auger wrote:
>> Hi Michael,
>
> Hi!
>
>> This commit added an imply ACPI_PCI to the PCI_EXPRESS_GENERIC_BRIDGE
>> config in hw/pci-host/Kconfig:
>>
>> config PCI_EXPRESS_GENERIC_BRIDGE
>>      bool
>>      select PCI_EXPRESS  -> selects PCI
>>      imply ACPI_PCI
>>
>> In hw/acpi/Kconfig we have:
>>
>> config ACPI_PCI
>>      bool
>>      depends on ACPI && PCI
>>
>> ACPI is selected by ACPI_HW_REDUCED
>>
>> config ACPI_HW_REDUCED
>>      bool
>>      select ACPI
>>      select ACPI_MEMORY_HOTPLUG
>>      select ACPI_NVDIMM
>>
>> so logically the ACPI && PCI dependencies for ACPI_PCI should be
>> resolved. What do I miss?
>
> I think it should be "select" not "imply", which seems to be stricter.
> With a devices file like I'm using - it looks like - only things which
> are selected gets enabled.  But this commit brings hard dependency
> between the bridge device and ACPI_PCI, as demonstrated by my example.
> So when the bridge selects ACPI_PCI instead of implying it, whole thing
> works (I just verified it)

build_pci_host_bridge_osc_method() is called from gpex-acpi.c

pci_ss.add(when: ['CONFIG_PCI_EXPRESS_GENERIC_BRIDGE', 'CONFIG_ACPI'],
if_true: files('gpex-acpi.c'))

so the hard dependency exists only if ACPI is selected.

If you use "select" you will force ACPI_PCI even if ACPI is not set
which does not sound what we want?

regards

Eric
>
> I wonder why we build microvm-only executable in debian...  Initially
> it was a small binary aimed at very fast startup and light runtime.
> But with time it grew quite a lot of things...
>
> Thanks,
>
> /mjt
>