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 09:14:37 +0100	[thread overview]
Message-ID: <20220207091437.52cf36b1@redhat.com> (raw)
In-Reply-To: <20220205124526.500158-3-f4bug@amsat.org>

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?


> 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  9:47 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 [this message]
2022-02-07  9:18     ` Igor Mammedov
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=20220207091437.52cf36b1@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.