| Message ID | 20220131233507.334174-2-f4bug@amsat.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hw/i386: QOM-attach CPUs/SGX-EPC objects to their parents | expand |
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
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.
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; }
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(+)