[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device |
Date: |
Wed, 16 Dec 2015 16:16:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
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)
- [Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects, (continued)
- [Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects, Bharata B Rao, 2015/12/10
- [Qemu-devel] [RFC PATCH v0 3/9] cpu: Don't realize CPU from cpu_generic_init(), Bharata B Rao, 2015/12/10
- [Qemu-devel] [RFC PATCH v0 7/9] spapr: Convert boot CPUs into CPU core device initialization, Bharata B Rao, 2015/12/10
- [Qemu-devel] [RFC PATCH v0 9/9] pc: Convert boot CPUs into CPU core device initialization, Bharata B Rao, 2015/12/10
- [Qemu-devel] [RFC PATCH v0 8/9] target-i386: Set apic_id during CPU initfn, Bharata B Rao, 2015/12/10
- Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device, Igor Mammedov, 2015/12/10
- Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device, Andreas Färber, 2015/12/16
- Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device, Bharata B Rao, 2015/12/31
Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device, Matthew Rosato, 2015/12/10
Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device, Andreas Färber, 2015/12/16