From: Igor Mammedov <imammedo@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "Yang Zhong" <yang.zhong@intel.com>,
"Jean-Philippe Brucker" <jean-philippe@linaro.org>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
libvir-list@redhat.com, qemu-devel@nongnu.org,
"Ani Sinha" <ani@anisinha.ca>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [PATCH v4 2/4] hw/i386: Attach CPUs to machine
Date: Mon, 7 Feb 2022 10:18:43 +0100 [thread overview]
Message-ID: <20220207101843.259f517c@redhat.com> (raw)
In-Reply-To: <20220207091437.52cf36b1@redhat.com>
On Mon, 7 Feb 2022 09:14:37 +0100
Igor Mammedov <imammedo@redhat.com> wrote:
> On Sat, 5 Feb 2022 13:45:24 +0100
> Philippe Mathieu-Daudé <f4bug@amsat.org> 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.
>
> Could you add to commit message the reason behind the change?
regardless, it looks like unwarranted movement to me
prompted by livirt accessing/expecting a QOM patch which is
not stable ABI. I'd rather get it fixed on libvirt side.
If libvirt needs for some reason access a CPU instance,
it should use @query-hotpluggable-cpus to get a list of CPUs
(which includes QOM path of already present CPUs) instead of
hard-codding some 'well-known' path as there is no any guarantee
that it will stay stable whatsoever.
> > Note: This (intentionally) breaks compatibility with current
> > libvirt code that looks for "/machine/unattached/device[0]"
> > in the assumption it is the first CPU.
> Why libvirt does this in the first place?
>
>
> > Cc: libvir-list@redhat.com
> > Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> > Reviewed-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));
>
> that will take in account only initial cpus, -device/device_add cpus
> will still go to wherever device_add attaches them (see qdev_set_id)
>
> > if (!object_property_set_uint(cpu, "apic-id", apic_id, errp)) {
> > goto out;
> > }
>
next prev parent reply other threads:[~2022-02-07 10:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-05 12:45 [PATCH v4 0/4] hw/i386: QOM-attach CPUs/SGX-EPC objects to their parents Philippe Mathieu-Daudé via
2022-02-05 12:45 ` [PATCH v4 1/4] tests/qtest/acpi: Temporary allow VIOT table changes Philippe Mathieu-Daudé via
2022-02-05 12:45 ` [PATCH v4 2/4] hw/i386: Attach CPUs to machine Philippe Mathieu-Daudé via
2022-02-07 8:14 ` Igor Mammedov
2022-02-07 9:18 ` Igor Mammedov [this message]
2022-02-07 9:36 ` Peter Krempa
2022-02-07 9:41 ` Peter Krempa
2022-02-07 11:20 ` Ani Sinha
2022-02-07 11:28 ` Peter Krempa
2022-02-07 11:37 ` Ani Sinha
2022-02-07 10:06 ` Daniel P. Berrangé
2022-02-07 11:22 ` Igor Mammedov
2022-02-07 11:48 ` Daniel P. Berrangé
2022-02-07 13:17 ` Igor Mammedov
2022-02-07 13:51 ` Peter Maydell
2022-02-05 12:45 ` [PATCH v4 3/4] tests/qtest/acpi: Update VIOT table blob Philippe Mathieu-Daudé via
2022-02-05 12:45 ` [PATCH v4 4/4] hw/i386/sgx: Attach SGX-EPC objects to machine Philippe Mathieu-Daudé via
2022-02-07 8:37 ` Igor Mammedov
2022-02-07 8:47 ` Philippe Mathieu-Daudé via
2022-02-14 6:58 ` Yang Zhong
2022-02-14 8:21 ` Igor Mammedov
2022-02-14 10:30 ` Daniel P. Berrangé
2022-02-16 9:01 ` Igor Mammedov
2022-02-14 7:27 ` Yang Zhong
2022-02-05 16:24 ` [PATCH v4 0/4] hw/i386: QOM-attach CPUs/SGX-EPC objects to their parents Philippe Mathieu-Daudé via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220207101843.259f517c@redhat.com \
--to=imammedo@redhat.com \
--cc=ani@anisinha.ca \
--cc=berrange@redhat.com \
--cc=f4bug@amsat.org \
--cc=jean-philippe@linaro.org \
--cc=libvir-list@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yang.zhong@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).