[Top][All Lists]

[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

> 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


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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]