All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: jan kiszka <jan.kiszka@siemens.com>,
	aliguori@us.ibm.com, qemu-devel@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 6/6] target-i386: make cpus childs of /machine
Date: Mon, 21 May 2012 16:50:22 +0200	[thread overview]
Message-ID: <4FBA562E.2020407@redhat.com> (raw)
In-Reply-To: <4FAAFA99.7000902@suse.de>

On 05/10/2012 01:15 AM, Andreas Färber wrote:
> Am 17.04.2012 12:28, schrieb Igor Mammedov:
>> ----- Original Message -----
>>> From: "Andreas Färber"<afaerber@suse.de>
...
>>>> I think the right name would be /machine/cpu[%d]/cpu.  The local
>>>> APIC
>>>> for example should reside under /machine/cpu[%d]/apic.
>>>
>>> Depends on how we model the CPU, I was kinda waiting for feedback on
>>> that.
>>>
>>> I would prefer /machine/cpu[%d], with the APIC being a child
>>> .../apic,
>>> if possible. That however depends on how the device'ification of the
>>> CPU
>> Ok, I'll change /machine/cpu%d to /machine/cpu[%d].
>
> Note that I needed a similar patch recently in my quest to move fields
> from CPU_COMMON into CPUState:
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu (WIP)
>
> current state:
> https://github.com/afaerber/qemu-cpu/commit/1318ad13cda52e694caea5cc72293c5879db3f9f
>
> I chose to do it in pc.c instead because for other architectures the
> placement will be a machine-specific decision.

I'm trying to re-base your commit on top of this series and doing it at board level
might be a problem if you think about doing hotplug in generalized way:

  1. create new obj instance for cpu
  2. set properties 'might include setting apic with its creation'
  3. realize obj instance

would it better to split name and cpu creation into 2 stages:

  - at board level: create links for all possible cpus
  - in target-XXX/cpu.c:XXX_cpu_initfn set appropriate link to itself (1)

and than any property that might need canonical path could be set in general way (2)?

Of cause this scheme is screwed up by the fact that there isn't canonical
path for links (cpu[xxx]). Any thoughts how to deal with it?
  - Can we use object_property_add_child at runtime to add new cpu to /machine, instead of link?


> I've used cpu_index, but it seems cpuid_apic_id is assigned only once,
> from cpu_index, so it should be identical. What's the difference?
Once Jan voiced that user visible cpu id, should be apic_id in context of cpu hotplug
(i.e. when doing: device_add xxx_cpu,id=12345,...)
   "Jan, please correct me if I've got you wrong."
So QOM tree probably should reflect this id and not cpu_index.

However cpu_index and apic_id are the same now and bios assumes it as well.
What are possible benefits of using cpuid_apic_id != cpu_index for qemu?

-- 
-----
  Igor

  parent reply	other threads:[~2012-05-21 14:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <72a3d008-2d67-47e8-b5f2-927ff5cf2166@zmail16.collab.prod.int.phx2.redhat.com>
2012-05-09 23:15 ` [Qemu-devel] [PATCH RFC 6/6] target-i386: make cpus childs of /machine Andreas Färber
2012-05-10  6:57   ` Paolo Bonzini
2012-05-10  9:51     ` Andreas Färber
2012-05-10 10:00       ` Paolo Bonzini
2012-05-21 14:50   ` Igor Mammedov [this message]
2012-05-21 15:01     ` Jan Kiszka

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=4FBA562E.2020407@redhat.com \
    --to=imammedo@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.