qemu-devel
[Top][All Lists]
Advanced

[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:46:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Am 10.12.2015 um 13:35 schrieb Igor Mammedov:
> wrt CLI can't we do something like this?
> 
> -device some-cpu-model,socket=x[,core=y[,thread=z]]

That's problematic and where my x86 remodeling got stuck. It works fine
(more or less) to model sockets, cores and hyperthreads for -smp, but
doing it dynamically did not work well. How do you determine the
instance size a socket with N cores and M threads needs? Allocations in
instance_init are to be avoided with a view to hot-plug. So either we
have a fully determined socket object or we need to wire individual
objects on the command line. The latter has bad implications for
atomicity and thus hot-unplug. That leaves us with dynamic properties
doing allocations and reporting it via Error**, something I never
finished and could use reviewers and contributors.

Anthony's old suggestion had been to use real socket product names like
Xeon-E5-4242 to get a 6-core, dual-thread socket, without parameters -
unfortunately I still don't see an easy way to define such a thing today
with the flexibility users will undoubtedly want.

And since the question came up how to detect this, what you guys seem to
keep forgetting is that somewhere there also needs to be a matching
link<> property that determines what can be plugged, i.e. QMP qom-list.
link<>s are the QOM equivalent to qdev's buses. The object itself needs
to live in /machine/peripheral or /machine/peripheral-anon
(/machine/unattached is supposed to go away after the QOM conversion is
done!) and in a machine-specific place there will be a
/machine/cpu-socket[0] -> /machine/peripheral-anon/device[42]
link<x86_64-cpu-socket> property. It might just as well be
/machine/daughterboard-x/cpu-core[2] -> /machine/peripheral/cpu0.
(Gentle reminder of the s390 ipi modeling discussion that never came to
any conclusion iirc.)

Note that I have not read this patch series yet, just some of the
alarming review comments.

Regards,
Andreas

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



reply via email to

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