gpex build_host_bridge_osc() and x86 originated
build_pci_host_bridge_osc_method() are mostly identical.
In GPEX, SUPP is set to CDW2 but is not further used. CTRL
is same as Local0.
So let gpex code reuse build_pci_host_bridge_osc_method()
and remove build_host_bridge_osc().
Also add an imply ACPI_PCI clause along with
PCI_EXPRESS_GENERIC_BRIDGE to compile hw/acpi/pci.c
when its dependency is resolved (ie. CONFIG_ACPI_PCI).
This is requested to link qemu-system-mips64el.
The disassembled DSDT difference is given below:
* Original Table Header:
* Signature "DSDT"
- * Length 0x00001A4F (6735)
+ * Length 0x00001A35 (6709)
* Revision 0x02
- * Checksum 0xBF
+ * Checksum 0xDD
* OEM ID "BOCHS "
* OEM Table ID "BXPC "
* OEM Revision 0x00000001 (1)
@@ -1849,27 +1849,26 @@ DefinitionBlock ("", "DSDT", 2, "BOCHS ", "BXPC ", 0x00000001)
{
CreateDWordField (Arg3, 0x04, CDW2)
CreateDWordField (Arg3, 0x08, CDW3)
- SUPP = CDW2 /* \_SB_.PCI0._OSC.CDW2 */
- CTRL = CDW3 /* \_SB_.PCI0._OSC.CDW3 */
- CTRL &= 0x1F
+ Local0 = CDW3 /* \_SB_.PCI0._OSC.CDW3 */
+ Local0 &= 0x1F
If ((Arg1 != One))
{
CDW1 |= 0x08
}
- If ((CDW3 != CTRL))
+ If ((CDW3 != Local0))
{
CDW1 |= 0x10
}
- CDW3 = CTRL /* \_SB_.PCI0.CTRL */
- Return (Arg3)
+ CDW3 = Local0
}
Else
{
CDW1 |= 0x04
- Return (Arg3)
}
+
+ Return (Arg3)
}
Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
---
v3 -> v4:
- Fix link issue:
/usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in function `acpi_dsdt_add_host_bridge_methods':
./hw/pci-host/gpex-acpi.c:83: undefined reference to `build_pci_host_bridge_osc_method'
v1 -> v2:
- move in the dsdt.dsl diff in the commit message and remove useless
info (Gustavo, Michael)
---
hw/pci-host/gpex-acpi.c | 62 ++++-------------------------------------
hw/pci-host/Kconfig | 1 +
2 files changed, 6 insertions(+), 57 deletions(-)
diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c
index 44737a8d81..952a0ace19 100644
--- a/hw/pci-host/gpex-acpi.c
+++ b/hw/pci-host/gpex-acpi.c
@@ -1,5 +1,6 @@
#include "qemu/osdep.h"
#include "hw/acpi/aml-build.h"
+#include "hw/acpi/pci.h"
#include "hw/pci-host/gpex.h"
#include "hw/arm/virt.h"
#include "hw/pci/pci_bus.h"
@@ -50,61 +51,7 @@ static void acpi_dsdt_add_pci_route_table(Aml *dev, uint32_t irq,
}
}
-static Aml *build_host_bridge_osc(bool enable_native_pcie_hotplug)
-{
- Aml *method, *UUID, *ifctx, *ifctx1, *elsectx;
- method = aml_method("_OSC", 4, AML_NOTSERIALIZED);
- aml_append(method, aml_name_decl("SUPP", aml_int(0)));
- aml_append(method, aml_name_decl("CTRL", aml_int(0)));
- aml_append(method,
- aml_create_dword_field(aml_arg(3), aml_int(0), "CDW1"));
-
- /* PCI Firmware Specification 3.0
- * 4.5.1. _OSC Interface for PCI Host Bridge Devices
- * The _OSC interface for a PCI/PCI-X/PCI Express hierarchy is
- * identified by the Universal Unique IDentifier (UUID)
- * 33DB4D5B-1FF7-401C-9657-7441C03DD766
- */
- UUID = aml_touuid("33DB4D5B-1FF7-401C-9657-7441C03DD766");
- ifctx = aml_if(aml_equal(aml_arg(0), UUID));
- aml_append(ifctx,
- aml_create_dword_field(aml_arg(3), aml_int(4), "CDW2"));
- aml_append(ifctx,
- aml_create_dword_field(aml_arg(3), aml_int(8), "CDW3"));
- aml_append(ifctx, aml_store(aml_name("CDW2"), aml_name("SUPP")));
- aml_append(ifctx, aml_store(aml_name("CDW3"), aml_name("CTRL")));
-
- /*
- * Allow OS control for SHPCHotplug, PME, AER, PCIeCapability,
- * and PCIeHotplug depending on enable_native_pcie_hotplug
- */
- aml_append(ifctx, aml_and(aml_name("CTRL"),
- aml_int(0x1E | (enable_native_pcie_hotplug ? 0x1 : 0x0)),
- aml_name("CTRL")));
-
- ifctx1 = aml_if(aml_lnot(aml_equal(aml_arg(1), aml_int(0x1))));
- aml_append(ifctx1, aml_or(aml_name("CDW1"), aml_int(0x08),
- aml_name("CDW1")));
- aml_append(ifctx, ifctx1);
-
- ifctx1 = aml_if(aml_lnot(aml_equal(aml_name("CDW3"), aml_name("CTRL"))));
- aml_append(ifctx1, aml_or(aml_name("CDW1"), aml_int(0x10),
- aml_name("CDW1")));
- aml_append(ifctx, ifctx1);
-
- aml_append(ifctx, aml_store(aml_name("CTRL"), aml_name("CDW3")));
- aml_append(ifctx, aml_return(aml_arg(3)));
- aml_append(method, ifctx);
-
- elsectx = aml_else();
- aml_append(elsectx, aml_or(aml_name("CDW1"), aml_int(4),
- aml_name("CDW1")));
- aml_append(elsectx, aml_return(aml_arg(3)));
- aml_append(method, elsectx);
- return method;
-}
-
-static Aml *build_host_bridge_dsm(void)
+static Aml *build_pci_host_bridge_dsm_method(void)
{
Aml *method = aml_method("_DSM", 4, AML_NOTSERIALIZED);
Aml *UUID, *ifctx, *ifctx1, *buf;
@@ -133,8 +80,9 @@ static void acpi_dsdt_add_host_bridge_methods(Aml *dev,
bool enable_native_pcie_hotplug)
{
/* Declare an _OSC (OS Control Handoff) method */
- aml_append(dev, build_host_bridge_osc(enable_native_pcie_hotplug));
- aml_append(dev, build_host_bridge_dsm());
+ aml_append(dev,
+ build_pci_host_bridge_osc_method(enable_native_pcie_hotplug));
+ aml_append(dev, build_pci_host_bridge_dsm_method());
}
void acpi_dsdt_add_gpex(Aml *scope, struct GPEXConfig *cfg)
diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
index 35c0415242..9824fa188d 100644
--- a/hw/pci-host/Kconfig
+++ b/hw/pci-host/Kconfig
@@ -54,6 +54,7 @@ config PCI_EXPRESS_Q35
config PCI_EXPRESS_GENERIC_BRIDGE
bool
select PCI_EXPRESS
+ imply ACPI_PCI
config PCI_EXPRESS_XILINX
bool
--
2.49.0On 14.07.2025 11:04, Eric Auger wrote: > gpex build_host_bridge_osc() and x86 originated > build_pci_host_bridge_osc_method() are mostly identical. > > In GPEX, SUPP is set to CDW2 but is not further used. CTRL > is same as Local0. > > So let gpex code reuse build_pci_host_bridge_osc_method() > and remove build_host_bridge_osc(). > > Also add an imply ACPI_PCI clause along with > PCI_EXPRESS_GENERIC_BRIDGE to compile hw/acpi/pci.c > when its dependency is resolved (ie. CONFIG_ACPI_PCI). > This is requested to link qemu-system-mips64el. This patch somehow broke microvm-only build which is used by debian. configure options used (trimmed a bit): ../configure \ --without-default-features \ --target-list=x86_64-softmmu \ --enable-kvm --disable-tcg \ --enable-pixman \ --enable-vnc \ --audio-drv-list="" \ --without-default-devices \ --with-devices-x86_64=microvm \ --enable-vhost-user configs/devices/x86_64-softmmu/microvm.mak: ---- cut ---- # see configs/devices/i386-softmmu/default.mak # for additional devices which can be disabled # CONFIG_PCI_DEVICES=n CONFIG_MICROVM=y CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_SERIAL=y CONFIG_VIRTIO_INPUT=y CONFIG_VIRTIO_INPUT_HOST=y CONFIG_VHOST_USER_INPUT=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_SCSI=y CONFIG_VIRTIO_RNG=y CONFIG_VIRTIO_CRYPTO=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_GPU=y CONFIG_VHOST_USER_GPU=y ---- cut ---- The result: FAILED: qemu-system-x86_64 cc -m64 @qemu-system-x86_64.rsp /usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in function `acpi_dsdt_add_host_bridge_methods': hw/pci-host/gpex-acpi.c:83:(.text+0x274): undefined reference to `build_pci_host_bridge_osc_method' collect2: error: ld returned 1 exit status Is it because my devices file wrong now, or some `select FOO` kconfig is missing? Should this code be enabled with this configuration anyway? Thanks, /mjt
On 27.07.2025 14:48, Michael Tokarev wrote: > On 14.07.2025 11:04, Eric Auger wrote: >> gpex build_host_bridge_osc() and x86 originated >> build_pci_host_bridge_osc_method() are mostly identical. >> >> In GPEX, SUPP is set to CDW2 but is not further used. CTRL is >> same as Local0. >> >> So let gpex code reuse build_pci_host_bridge_osc_method() and >> remove build_host_bridge_osc(). >> >> Also add an imply ACPI_PCI clause along with >> PCI_EXPRESS_GENERIC_BRIDGE to compile hw/acpi/pci.c when its >> dependency is resolved (ie. CONFIG_ACPI_PCI). This is requested >> to link qemu-system-mips64el. > > This patch somehow broke microvm-only build which is used by debian. > > configure options used (trimmed a bit): > > ../configure \ --without-default-features \ --target-list=x86_64- > softmmu \ --enable-kvm --disable-tcg \ --enable-pixman \ --enable- > vnc \ --audio-drv-list="" \ --without-default-devices \ --with- > devices-x86_64=microvm \ --enable-vhost-user > > configs/devices/x86_64-softmmu/microvm.mak: ---- cut ---- # see > configs/devices/i386-softmmu/default.mak # for additional devices > which can be disabled # CONFIG_PCI_DEVICES=n > > CONFIG_MICROVM=y > > CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_SERIAL=y CONFIG_VIRTIO_INPUT=y > CONFIG_VIRTIO_INPUT_HOST=y CONFIG_VHOST_USER_INPUT=y > CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_SCSI=y CONFIG_VIRTIO_RNG=y > CONFIG_VIRTIO_CRYPTO=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_GPU=y > CONFIG_VHOST_USER_GPU=y ---- cut ---- > > The result: FAILED: qemu-system-x86_64 cc -m64 @qemu-system- > x86_64.rsp /usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in > function `acpi_dsdt_add_host_bridge_methods': hw/pci-host/gpex- > acpi.c:83:(.text+0x274): undefined reference to > `build_pci_host_bridge_osc_method' collect2: error: ld returned 1 > exit status In hw/i386/Kconfig, MICROVM selects ACPI_HW_REDUCED (not ACPI or ACPI_PCI), *and* PCI_EXPRESS_GENERIC_BRIDGE. But in hw/pci/meson.build, pci.c (where the function in question is defined) is built when ACPI_PCI is enabled. Something's not right here. Addig kraxel for 24db877ab6e6 "microvm: add pcie support". Thanks /mjt
Hi Michael, On 7/28/25 11:07 AM, Michael Tokarev wrote: > On 27.07.2025 14:48, Michael Tokarev wrote: >> On 14.07.2025 11:04, Eric Auger wrote: >>> gpex build_host_bridge_osc() and x86 originated >>> build_pci_host_bridge_osc_method() are mostly identical. >>> >>> In GPEX, SUPP is set to CDW2 but is not further used. CTRL is >>> same as Local0. >>> >>> So let gpex code reuse build_pci_host_bridge_osc_method() and remove >>> build_host_bridge_osc(). >>> >>> Also add an imply ACPI_PCI clause along with >>> PCI_EXPRESS_GENERIC_BRIDGE to compile hw/acpi/pci.c when its >>> dependency is resolved (ie. CONFIG_ACPI_PCI). This is requested >>> to link qemu-system-mips64el. >> >> This patch somehow broke microvm-only build which is used by debian. >> >> configure options used (trimmed a bit): >> >> ../configure \ --without-default-features \ --target-list=x86_64- >> softmmu \ --enable-kvm --disable-tcg \ --enable-pixman \ --enable- >> vnc \ --audio-drv-list="" \ --without-default-devices \ --with- >> devices-x86_64=microvm \ --enable-vhost-user >> >> configs/devices/x86_64-softmmu/microvm.mak: ---- cut ---- # see >> configs/devices/i386-softmmu/default.mak # for additional devices >> which can be disabled # CONFIG_PCI_DEVICES=n >> >> CONFIG_MICROVM=y >> >> CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_SERIAL=y CONFIG_VIRTIO_INPUT=y >> CONFIG_VIRTIO_INPUT_HOST=y CONFIG_VHOST_USER_INPUT=y >> CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_SCSI=y CONFIG_VIRTIO_RNG=y >> CONFIG_VIRTIO_CRYPTO=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_GPU=y >> CONFIG_VHOST_USER_GPU=y ---- cut ---- >> >> The result: FAILED: qemu-system-x86_64 cc -m64 @qemu-system- >> x86_64.rsp /usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in >> function `acpi_dsdt_add_host_bridge_methods': hw/pci-host/gpex- >> acpi.c:83:(.text+0x274): undefined reference to >> `build_pci_host_bridge_osc_method' collect2: error: ld returned 1 >> exit status > > In hw/i386/Kconfig, MICROVM selects ACPI_HW_REDUCED (not ACPI or > ACPI_PCI), *and* PCI_EXPRESS_GENERIC_BRIDGE. But in hw/pci/meson.build, > pci.c (where the function in question is defined) is built when > ACPI_PCI is enabled. Something's not right here. 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? regards Eric > > Addig kraxel for 24db877ab6e6 "microvm: add pcie support". > > Thanks > > /mjt >
On Mon, Jul 28, 2025 at 04:56:37PM +0200, Eric Auger wrote: > Hi Michael, > > On 7/28/25 11:07 AM, Michael Tokarev wrote: > > On 27.07.2025 14:48, Michael Tokarev wrote: > >> On 14.07.2025 11:04, Eric Auger wrote: > >>> gpex build_host_bridge_osc() and x86 originated > >>> build_pci_host_bridge_osc_method() are mostly identical. > >>> > >>> In GPEX, SUPP is set to CDW2 but is not further used. CTRL is > >>> same as Local0. > >>> > >>> So let gpex code reuse build_pci_host_bridge_osc_method() and remove > >>> build_host_bridge_osc(). > >>> > >>> Also add an imply ACPI_PCI clause along with > >>> PCI_EXPRESS_GENERIC_BRIDGE to compile hw/acpi/pci.c when its > >>> dependency is resolved (ie. CONFIG_ACPI_PCI). This is requested > >>> to link qemu-system-mips64el. > >> > >> This patch somehow broke microvm-only build which is used by debian. > >> > >> configure options used (trimmed a bit): > >> > >> ../configure \ --without-default-features \ --target-list=x86_64- > >> softmmu \ --enable-kvm --disable-tcg \ --enable-pixman \ --enable- > >> vnc \ --audio-drv-list="" \ --without-default-devices \ --with- > >> devices-x86_64=microvm \ --enable-vhost-user > >> > >> configs/devices/x86_64-softmmu/microvm.mak: ---- cut ---- # see > >> configs/devices/i386-softmmu/default.mak # for additional devices > >> which can be disabled # CONFIG_PCI_DEVICES=n > >> > >> CONFIG_MICROVM=y > >> > >> CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_SERIAL=y CONFIG_VIRTIO_INPUT=y > >> CONFIG_VIRTIO_INPUT_HOST=y CONFIG_VHOST_USER_INPUT=y > >> CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_SCSI=y CONFIG_VIRTIO_RNG=y > >> CONFIG_VIRTIO_CRYPTO=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_GPU=y > >> CONFIG_VHOST_USER_GPU=y ---- cut ---- > >> > >> The result: FAILED: qemu-system-x86_64 cc -m64 @qemu-system- > >> x86_64.rsp /usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in > >> function `acpi_dsdt_add_host_bridge_methods': hw/pci-host/gpex- > >> acpi.c:83:(.text+0x274): undefined reference to > >> `build_pci_host_bridge_osc_method' collect2: error: ld returned 1 > >> exit status > > > > In hw/i386/Kconfig, MICROVM selects ACPI_HW_REDUCED (not ACPI or > > ACPI_PCI), *and* PCI_EXPRESS_GENERIC_BRIDGE. But in hw/pci/meson.build, > > pci.c (where the function in question is defined) is built when > > ACPI_PCI is enabled. Something's not right here. > 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? > regards > > Eric > Not sure I get what are you proposing? > > > > > > > > > > > Addig kraxel for 24db877ab6e6 "microvm: add pcie support". > > > > Thanks > > > > /mjt > >
Hi Michael, On 8/1/25 2:29 PM, Michael S. Tsirkin wrote: > On Mon, Jul 28, 2025 at 04:56:37PM +0200, Eric Auger wrote: >> Hi Michael, >> >> On 7/28/25 11:07 AM, Michael Tokarev wrote: >>> On 27.07.2025 14:48, Michael Tokarev wrote: >>>> On 14.07.2025 11:04, Eric Auger wrote: >>>>> gpex build_host_bridge_osc() and x86 originated >>>>> build_pci_host_bridge_osc_method() are mostly identical. >>>>> >>>>> In GPEX, SUPP is set to CDW2 but is not further used. CTRL is >>>>> same as Local0. >>>>> >>>>> So let gpex code reuse build_pci_host_bridge_osc_method() and remove >>>>> build_host_bridge_osc(). >>>>> >>>>> Also add an imply ACPI_PCI clause along with >>>>> PCI_EXPRESS_GENERIC_BRIDGE to compile hw/acpi/pci.c when its >>>>> dependency is resolved (ie. CONFIG_ACPI_PCI). This is requested >>>>> to link qemu-system-mips64el. >>>> This patch somehow broke microvm-only build which is used by debian. >>>> >>>> configure options used (trimmed a bit): >>>> >>>> ../configure \ --without-default-features \ --target-list=x86_64- >>>> softmmu \ --enable-kvm --disable-tcg \ --enable-pixman \ --enable- >>>> vnc \ --audio-drv-list="" \ --without-default-devices \ --with- >>>> devices-x86_64=microvm \ --enable-vhost-user >>>> >>>> configs/devices/x86_64-softmmu/microvm.mak: ---- cut ---- # see >>>> configs/devices/i386-softmmu/default.mak # for additional devices >>>> which can be disabled # CONFIG_PCI_DEVICES=n >>>> >>>> CONFIG_MICROVM=y >>>> >>>> CONFIG_VIRTIO_BLK=y CONFIG_VIRTIO_SERIAL=y CONFIG_VIRTIO_INPUT=y >>>> CONFIG_VIRTIO_INPUT_HOST=y CONFIG_VHOST_USER_INPUT=y >>>> CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_SCSI=y CONFIG_VIRTIO_RNG=y >>>> CONFIG_VIRTIO_CRYPTO=y CONFIG_VIRTIO_BALLOON=y CONFIG_VIRTIO_GPU=y >>>> CONFIG_VHOST_USER_GPU=y ---- cut ---- >>>> >>>> The result: FAILED: qemu-system-x86_64 cc -m64 @qemu-system- >>>> x86_64.rsp /usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in >>>> function `acpi_dsdt_add_host_bridge_methods': hw/pci-host/gpex- >>>> acpi.c:83:(.text+0x274): undefined reference to >>>> `build_pci_host_bridge_osc_method' collect2: error: ld returned 1 >>>> exit status >>> In hw/i386/Kconfig, MICROVM selects ACPI_HW_REDUCED (not ACPI or >>> ACPI_PCI), *and* PCI_EXPRESS_GENERIC_BRIDGE. But in hw/pci/meson.build, >>> pci.c (where the function in question is defined) is built when >>> ACPI_PCI is enabled. Something's not right here. >> 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? >> regards >> >> Eric >> > > Not sure I get what are you proposing? I have not proposed anything ;-) - sorry I am on vacation - I was trying to enumerate the various config settings and to me dependencies should be resolved so I fail to understand. Unfortunately I cannot test because the problem happens with a custom microvm.mak. I would need this latter to reproduce and try to fix. if the microvm.mak selects PCI_EXPRESS_GENERIC_BRIDGE (which selects PCI_EXPRESS which itself selects PCI) and ACPI_HW_REDUCED (which selects ACPI), the imply ACPI_PCI should end up as a selection because PCI and ACPI are resolved. At least that's my understanding. Reading it again, please can you check whether ACPI_HW_REDUCED is selected *before* PCI_EXPRESS_GENERIC_BRIDGE in the custom microvm.mak. Depending on the order of dependency resolution it might make a difference. Otherwise please can you send the full microvm.mak and configure command so that I can try reproducing. Thanks Eric > >> >> >> >> >> >> >>> Addig kraxel for 24db877ab6e6 "microvm: add pcie support". >>> >>> Thanks >>> >>> /mjt >>>
On 03.08.2025 19:49, Eric Auger wrote: ... > I have not proposed anything ;-) - sorry I am on vacation - I was trying > to enumerate the various config settings and to me dependencies should > be resolved so I fail to understand. Unfortunately I cannot test because > the problem happens with a custom microvm.mak. I would need this latter > to reproduce and try to fix. > > if the microvm.mak selects PCI_EXPRESS_GENERIC_BRIDGE (which selects > PCI_EXPRESS which itself selects PCI) and ACPI_HW_REDUCED (which selects > ACPI), the imply ACPI_PCI should end up as a selection because PCI and > ACPI are resolved. At least that's my understanding. Reading it again, > please can you check whether ACPI_HW_REDUCED is selected *before* > PCI_EXPRESS_GENERIC_BRIDGE in the custom microvm.mak. Depending on the > order of dependency resolution it might make a difference. Otherwise > please can you send the full microvm.mak and configure command so that I > can try reproducing. Thanks Eric All the details were in my very first reply to the original patch: https://lore.kernel.org/qemu-devel/ddf6f9e3-daaa-4ea1-a5e6-d402a75524c8@tls.msk.ru/ Thanks, /mjt
Hi Michael, On 8/4/25 8:29 AM, Michael Tokarev wrote: > On 03.08.2025 19:49, Eric Auger wrote: > ... >> I have not proposed anything ;-) - sorry I am on vacation - I was trying >> to enumerate the various config settings and to me dependencies should >> be resolved so I fail to understand. Unfortunately I cannot test because >> the problem happens with a custom microvm.mak. I would need this latter >> to reproduce and try to fix. >> >> if the microvm.mak selects PCI_EXPRESS_GENERIC_BRIDGE (which selects >> PCI_EXPRESS which itself selects PCI) and ACPI_HW_REDUCED (which selects >> ACPI), the imply ACPI_PCI should end up as a selection because PCI and >> ACPI are resolved. At least that's my understanding. Reading it again, >> please can you check whether ACPI_HW_REDUCED is selected *before* >> PCI_EXPRESS_GENERIC_BRIDGE in the custom microvm.mak. Depending on the >> order of dependency resolution it might make a difference. Otherwise >> please can you send the full microvm.mak and configure command so that I >> can try reproducing. Thanks Eric > > All the details were in my very first reply to the original patch: > https://lore.kernel.org/qemu-devel/ddf6f9e3-daaa-4ea1-a5e6-d402a75524c8@tls.msk.ru/ > Sorry I was confused by the fact the microvm.mak was not upstream and its content was cut in your original report. I was able to reproduce and could check that both ACPI and PCI are set since objects that depend on them are compiled. However ACPI_PCI which depend on both and which is implied by PCI_EXPRESS_GENERIC_BRIDGE is not set as opposed to what I would have expected. So I sent "[PATCH for 10.1] microvm: Explicitly select ACPI_PCI" as a tentative fix of your issue. It looks similar to PC setup. An alternative could be to set it in your .mak file. Nevetheless I still fail to understand what prevents the imply from beeing active as a select here. Maybe that's due to the "eveythning unset by default". Thanks Eric > > Thanks, > > /mjt >
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) 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
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
>
On 28.07.2025 18:17, Michael Tokarev wrote: > 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) I just sent a patch doing exactly that. Alternatively this can be #ifdef ACPI_PCI in the code, - I dunno if that's possible now. Thanks, /mjt
© 2016 - 2025 Red Hat, Inc.