[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 00/10] cpu: add device_add foo-x86_64-cpu sup
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH v4 00/10] cpu: add device_add foo-x86_64-cpu support |
Date: |
Thu, 26 Feb 2015 10:08:04 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Am 26.02.2015 um 05:42 schrieb Bharata B Rao:
> On Tue, Feb 24, 2015 at 05:56:45PM +0100, Andreas Färber wrote:
>> Am 24.02.2015 um 02:25 schrieb Gu Zheng:
>>> The issues you commented in the previous version have been fixed in this
>>> one.
>>
>> What I have repeatedly rejected is "device_add foo-x86_64-cpu". This is
>> still in 00/10 and 09/10. Most of the actual changes however do look to
>> be going in the right direction of making 'realize' work as expected for
>> foo-x86_64-cpu.
>>
>> As for the socket-based device_add I mentioned, I had pushed a work
>> branch qom-cpu-x86 and had some off-list discussions for some of the
>> other architectures but did not submit it as an RFC yet. What I am still
>> working on is dynamic properties to allocate cores (threads TBD) for
>> "device_add x86_64-cpu-socket,cores=n".
>
> If you have started a VM with -smp sockets=1,cores=4,threads=2, will you
> allow addition of a socket with just 2 cores like
>
> device_add x86_64-cpu-socket,cores=2,id=sock2 ?
In my implementation it is not yet working; with your patch it might,
from a QEMU perspective. Whether that is sensible to do on x86
ACPI-/guest-wise is a different question. I didn't want to rule it out,
as it seems possible in hardware when Intel/AMD socket types are
compatible, and today cpu-add adds them one by one so it's possible.
On PowerPC the modeling could be done slightly differently, but as for
x86 we'll have to keep in mind that there's not just sPAPR but also
baremetal.
> If so, will there be semantics to populate the remaining cores of that
> socket ? If so, would that look like below ?
>
> device-add x86_64-cpu-core,sock=sock2
No, that is not possible with my modeling. Hotplug possibilities
correspond to link<> properties, whereas my socket proposal uses child<>
properties. This in turn has implications on CPU initialization
functions, needing to not set realized=true. For non-x86 that will
involve taking realized=true out of cpu_init() and moving it into call
sites.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
- [Qemu-devel] [PATCH v4 04/10] cpu: introduce get_compat_arch_id() method and override it for X86CPU, (continued)
- [Qemu-devel] [PATCH v4 04/10] cpu: introduce get_compat_arch_id() method and override it for X86CPU, Zhu Guihua, 2015/02/13
- [Qemu-devel] [PATCH v4 05/10] qom/cpu: move register_vmstate to common CPUClass.realizefn, Zhu Guihua, 2015/02/13
- [Qemu-devel] [PATCH v4 07/10] monitor: use cc->get_arch_id as the cpu index, Zhu Guihua, 2015/02/13
- [Qemu-devel] [PATCH v4 08/10] acpi: introduce acpi_send_gpe_event(), Zhu Guihua, 2015/02/13
- [Qemu-devel] [PATCH v4 09/10] cpu: add device_add foo-x86_64-cpu support, Zhu Guihua, 2015/02/13
- [Qemu-devel] [PATCH v4 10/10] i386/cpu: add instance finalize callback, Zhu Guihua, 2015/02/13
- Re: [Qemu-devel] [PATCH v4 00/10] cpu: add device_add foo-x86_64-cpu support, Gu Zheng, 2015/02/23