Previously CPUs were exposed in the QOM tree at a path
/machine/unattached/device[nn]
where the 'nn' of the first CPU is usually zero, but can
vary depending on what devices were already created.
With this change the CPUs are now at
/machine/cpu[nn]
where the 'nn' of the first CPU is always zero.
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
hw/i386/x86.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index b84840a1bb9..50bf249c700 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -108,6 +108,7 @@ void x86_cpu_new(X86MachineState *x86ms, int64_t apic_id, Error **errp)
{
Object *cpu = object_new(MACHINE(x86ms)->cpu_type);
+ object_property_add_child(OBJECT(x86ms), "cpu[*]", OBJECT(cpu));
if (!object_property_set_uint(cpu, "apic-id", apic_id, errp)) {
goto out;
}
--
2.34.1
Cc libvir-list since this will (intentionally) break compatibility
with current libvirt code that looks for "/machine/unattached/device[0]"
in the assumption it is the first CPU.
On Tue, Feb 01, 2022 at 12:35:06AM +0100, Philippe Mathieu-Daudé wrote:
> Previously CPUs were exposed in the QOM tree at a path
>
> /machine/unattached/device[nn]
>
> where the 'nn' of the first CPU is usually zero, but can
> vary depending on what devices were already created.
>
> With this change the CPUs are now at
>
> /machine/cpu[nn]
>
> where the 'nn' of the first CPU is always zero.
>
> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/i386/x86.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
>
> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> index b84840a1bb9..50bf249c700 100644
> --- a/hw/i386/x86.c
> +++ b/hw/i386/x86.c
> @@ -108,6 +108,7 @@ void x86_cpu_new(X86MachineState *x86ms, int64_t apic_id, Error **errp)
> {
> Object *cpu = object_new(MACHINE(x86ms)->cpu_type);
>
> + object_property_add_child(OBJECT(x86ms), "cpu[*]", OBJECT(cpu));
> if (!object_property_set_uint(cpu, "apic-id", apic_id, errp)) {
> goto out;
> }
> --
> 2.34.1
>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
This is causing breakage in the acpi-tables-test, sorry.
Paolo
Il mar 1 feb 2022, 00:35 Philippe Mathieu-Daudé <f4bug@amsat.org> ha
scritto:
> Previously CPUs were exposed in the QOM tree at a path
>
> /machine/unattached/device[nn]
>
> where the 'nn' of the first CPU is usually zero, but can
> vary depending on what devices were already created.
>
> With this change the CPUs are now at
>
> /machine/cpu[nn]
>
> where the 'nn' of the first CPU is always zero.
>
> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/i386/x86.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
> index b84840a1bb9..50bf249c700 100644
> --- a/hw/i386/x86.c
> +++ b/hw/i386/x86.c
> @@ -108,6 +108,7 @@ void x86_cpu_new(X86MachineState *x86ms, int64_t
> apic_id, Error **errp)
> {
> Object *cpu = object_new(MACHINE(x86ms)->cpu_type);
>
> + object_property_add_child(OBJECT(x86ms), "cpu[*]", OBJECT(cpu));
> if (!object_property_set_uint(cpu, "apic-id", apic_id, errp)) {
> goto out;
> }
> --
> 2.34.1
>
>
On 4/2/22 18:59, Paolo Bonzini wrote: > This is causing breakage in the acpi-tables-test, sorry. $ make check-qtest-x86_64 Ok: 49 Expected Fail: 0 Fail: 0 Unexpected Pass: 0 Skipped: 7 Timeout: 0 $ make check-qtest-i386 Ok: 52 Expected Fail: 0 Fail: 0 Unexpected Pass: 0 Skipped: 4 Timeout: 0 I am confuse, how do you run it?
It broke check-system-debian in CI. Paolo Il ven 4 feb 2022, 20:31 Philippe Mathieu-Daudé <f4bug@amsat.org> ha scritto: > On 4/2/22 18:59, Paolo Bonzini wrote: > > This is causing breakage in the acpi-tables-test, sorry. > > $ make check-qtest-x86_64 > > Ok: 49 > Expected Fail: 0 > Fail: 0 > Unexpected Pass: 0 > Skipped: 7 > Timeout: 0 > > $ make check-qtest-i386 > > Ok: 52 > Expected Fail: 0 > Fail: 0 > Unexpected Pass: 0 > Skipped: 4 > Timeout: 0 > > I am confuse, how do you run it? > >
+Igor On 5/2/22 10:21, Paolo Bonzini wrote: > It broke check-system-debian in CI. OK. This is odd because I am using Ubuntu 20.04 x86_64 host and can not reproduce. I'll investigate. > Il ven 4 feb 2022, 20:31 Philippe Mathieu-Daudé <f4bug@amsat.org > <mailto:f4bug@amsat.org>> ha scritto: > > On 4/2/22 18:59, Paolo Bonzini wrote: > > This is causing breakage in the acpi-tables-test, sorry. > > $ make check-qtest-x86_64 > > Ok: 49 > Expected Fail: 0 > Fail: 0 > Unexpected Pass: 0 > Skipped: 7 > Timeout: 0 > > $ make check-qtest-i386 > > Ok: 52 > Expected Fail: 0 > Fail: 0 > Unexpected Pass: 0 > Skipped: 4 > Timeout: 0 > > I am confuse, how do you run it? >
On 5/2/22 11:32, Philippe Mathieu-Daudé wrote: > +Igor > > On 5/2/22 10:21, Paolo Bonzini wrote: >> It broke check-system-debian in CI. > > OK. This is odd because I am using Ubuntu 20.04 x86_64 host and > can not reproduce. I'll investigate. OK I could reproduce using the Docker image pulled from registry.gitlab.com/qemu-project/qemu/qemu/debian-amd64: acpi-test: Warning! VIOT binary file mismatch. Actual [aml:/tmp/aml-INVNG1], Expected [aml:tests/data/acpi/q35/VIOT.viot]. See source file tests/qtest/bios-tables-test.c for instructions on how to update expected files. to see ASL diff between mismatched files install IASL, rebuild QEMU from scratch and re-run tests with V=1 environment variable set** ERROR:../tests/qtest/bios-tables-test.c:531:test_acpi_asl: assertion failed: (all_tables_match) Bail out! ERROR:../tests/qtest/bios-tables-test.c:531:test_acpi_asl: assertion failed: (all_tables_match) Aborted (core dumped) I'll post a v4 silencing this warning, but I have no much clue about this. Phil.
© 2016 - 2026 Red Hat, Inc.