qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>,
	bharata@linux.vnet.ibm.com, Igor Mammedov <imammedo@redhat.com>
Cc: mjrosato@linux.vnet.ibm.com, peter.maydell@linaro.org,
	ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de,
	borntraeger@de.ibm.com, pbonzini@redhat.com,
	izumi.taku@jp.fujitsu.com, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device
Date: Wed, 16 Dec 2015 16:16:58 +0100	[thread overview]
Message-ID: <5671806A.5040002@suse.de> (raw)
In-Reply-To: <566FA4BF.6080709@cn.fujitsu.com>

Am 15.12.2015 um 06:27 schrieb Zhu Guihua:
> <snip>
>>> and allow individual targets to use its own way to build CPUs?
>>>
>>> For initial conversion of x86-cpus to device-add we could do pretty
>>> much the same like we do now, where cpu devices will appear under:
>>> /machine (pc-i440fx-2.5-machine)
>>>    /unattached (container)
>>>      /device[x] (qemu64-x86_64-cpu)
>>>
>>> since we don't have to maintain/model dummy socket/core objects.
>>>
>>> PowerPC could do the similar only at core level since it has
>>> need for modeling core objects.
>>>
>>> It doesn't change anything wrt current introspection state, since
>>> cpus could be still found by mgmt tools that parse QOM tree.
>>>
>>> We probably should split 2 conflicting goals we are trying to meet here,
>>>
>>>   1. make device-add/dell work with cpus /
>>>       drop support for cpu-add in favor of device_add
>>>
>>>   2. how to model QOM tree view for CPUs in arch independent manner
>>>      to make mgmt layer life easier.
>>>
>>> and work on them independently instead of arguing for years,
>>> that would allow us to make progress in #1 while still thinking about
>>> how to do #2 the right way if we really need it.
>> Makes sense, s390 developer also recommends the same. Given that we have
>> CPU hotplug patchsets from x86, PowerPC and s390 all implementing
>> device_add
>> semantics pending on the list, can we hope to get them merged for
>> QEMU-2.6 ?
>>
>> So as seen below, the device is either "cpu_model-cpu_type" or just
>> "cpu_type".
>>
>> -device POWER8-powerpc64-cpu (pseries)
>> -device qemu64-x86_64-cpu (pc)
>> -device s390-cpu (s390)
>>
>> Is this going to be the final acceptable semantics ? Would libvirt be
>> able
>> to work with this different CPU device names for different guests ?
> 
> Is operating on core level not final decision ?

No, it is absolutely _not_ the conclusion from Seattle.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

  reply	other threads:[~2015-12-16 15:17 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10  6:15 [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 1/9] vl: Don't allow CPU toplogies with partially filled cores Bharata B Rao
2015-12-10 10:25   ` Daniel P. Berrange
2015-12-11  3:24     ` Bharata B Rao
2015-12-14 17:37       ` Eduardo Habkost
2015-12-15  8:41         ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState Bharata B Rao
2015-12-14 17:29   ` Eduardo Habkost
2015-12-15  8:38     ` Bharata B Rao
2015-12-15 15:31       ` Eduardo Habkost
2015-12-16 16:54       ` Igor Mammedov
2015-12-16 19:39         ` Eduardo Habkost
2015-12-16 22:26           ` Igor Mammedov
2015-12-17 18:09             ` Eduardo Habkost
2015-12-18 10:46               ` Igor Mammedov
2015-12-18 15:51                 ` Eduardo Habkost
2015-12-18 16:01                   ` Igor Mammedov
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 3/9] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 4/9] cpu: CPU socket backend Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 6/9] cpu: Introduce CPU core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 7/9] spapr: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 8/9] target-i386: Set apic_id during CPU initfn Bharata B Rao
2015-12-14 17:44   ` Eduardo Habkost
2015-12-15  8:14     ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 9/9] pc: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10 12:35 ` [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Igor Mammedov
2015-12-11  3:57   ` Bharata B Rao
2015-12-15  5:27     ` Zhu Guihua
2015-12-16 15:16       ` Andreas Färber [this message]
2015-12-16 15:11     ` Igor Mammedov
2015-12-17  9:19       ` Peter Krempa
2015-12-16 15:46   ` Andreas Färber
2015-12-16 21:58     ` Igor Mammedov
2015-12-24  1:59       ` Zhu Guihua
2015-12-29 13:52         ` Igor Mammedov
2016-01-01  3:47     ` Bharata B Rao
2016-01-04 12:52       ` Igor Mammedov
2015-12-10 20:25 ` Matthew Rosato
2015-12-14  6:25   ` Bharata B Rao
2015-12-16 15:19 ` Andreas Färber
2015-12-16 15:44   ` Igor Mammedov
2015-12-16 15:57     ` Andreas Färber
2015-12-16 17:22       ` Igor Mammedov
2015-12-16 22:37         ` Igor Mammedov
2016-01-12  3:54         ` David Gibson

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=5671806A.5040002@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=mjrosato@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=zhugh.fnst@cn.fujitsu.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).