All of lore.kernel.org
 help / color / mirror / Atom feed
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;
> >      }  
> 



  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.