Re: [Qemu-devel] cpu modelling and hotplug

[Zhu Guihua <zhugh.fnst@cn.fujitsu.com>]

Hi all,

May I know whether the discussion is still ongoing?

I checked Andreas's git tree, there was no changes about the topology.

Plz let me know the schedule about this.

Thanks,
Zhu

On 04/07/2015 08:43 PM, Christian Borntraeger wrote:
> We had a call and I was asked to write a summary about our conclusion.
>
> The more I wrote, there more I became uncertain if we really came to a
> conclusion and became more certain that we want to define the QMP/HMP/CLI
> interfaces first (or quite early in the process)
>
> As discussed I will provide an initial document as a discussion starter
>
> So here is my current understanding with each piece of information on one line, so
> that everybody can correct me or make additions:
>
> current wrap-up of architecture support
> -------------------
> x86
> - Topology possible
>     - can be hierarchical
>     - interfaces to query topology
> - SMT: fanout in host, guest uses host threads to back guest vCPUS
> - supports cpu hotplug via cpu_add
>
> power
> - Topology possible
>     - interfaces to query topology?
> - SMT: Power8: no threads in host and full core passed in due to HW design
>         may change in the future
>
> s/390
> - Topology possible
>      - can be hierarchical
>      - interfaces to query topology
> - always virtualized via PR/SM LPAR
>      - host topology from LPAR can be heterogenous (e.g. 3 cpus in 1st socket, 4 in 2nd)
> - SMT: fanout in host, guest uses host threads to back guest vCPUS
>
>
> Current downsides of CPU definitions/hotplug
> -----------------------------------------------
> - smp, sockets=,cores=,threads= builds only homogeneous topology
> - cpu_add does not tell were to add
> - artificial icc bus construct on x86 for several reasons (link, sysbus not hotpluggable..)
>
>
> discussions
> -------------------
> - we want to be able to (most important question, IHMO)
>   - hotplug CPUs on power/x86/s390 and maybe others
>   - define topology information
>   - bind the guest topology to the host topology in some way
>      - to host nodes
>      - maybe also for gang scheduling of threads (might face reluctance from
>        the linux scheduler folks)
>      - not really deeply outlined in this call
> - QOM links must be allocated at boot time, but can be set later on
>      - nothing that we want to expose to users
>      - Machine provides QOM links that the device_add hotplug mechanism can use to add
>        new CPUs into preallocated slots. "CPUs" can be groups of cores and/or threads.
> - hotplug and initial config should use same semantics
> - cpu and memory topology might be somewhat independent
> --> - define nodes
>      - map CPUs to nodes
>      - map memory to nodes
>
> - hotplug per
>      - socket
>      - core
>      - thread
>      ?
> Now comes the part where I am not sure if we came to a conclusion or not:
> - hotplug/definition per core (but not per thread) seems to handle all cases
>      - core might have multiple threads ( and thus multiple cpustates)
>      - as device statement (or object?)
> - mapping of cpus to nodes or defining the topology not really
>    outlined in this call
>
> To be defined:
> - QEMU command line for initial setup
> - QEMU hmp/qmp interfaces for dynamic setup
>
>
> Christian
>
>
> .
>