From: Jan Kiszka <jan.kiszka@siemens.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"Andreas Färber" <afaerber@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH RFC 6/6] target-i386: make cpus childs of /machine
Date: Mon, 21 May 2012 12:01:39 -0300 [thread overview]
Message-ID: <4FBA58D3.30508@siemens.com> (raw)
In-Reply-To: <4FBA562E.2020407@redhat.com>
On 2012-05-21 11:50, Igor Mammedov wrote:
>> 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?
>From my POV, cpu_index could become equal to the physical APIC ID. As
long as we can set it freely (provided it remains unique) and
non-continuously, we don't need separate indexes.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
prev parent reply other threads:[~2012-05-21 15:01 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
2012-05-21 15:01 ` Jan Kiszka [this message]
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=4FBA58D3.30508@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=imammedo@redhat.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.