Re: [Qemu-devel] [RFC/PATCH 0/1] cpu hotplug for s390

[Eduardo Habkost]

On Fri, Apr 19, 2013 at 09:13:32PM +0200, Christian Borntraeger wrote:
> On 19/04/13 15:16, Andreas Färber wrote:
> [...]
> >>> Background is that for x86 we currently have a flat CPU core/thread
> >>> namespace but would need to deal with sockets, cores and threads to get
> >>> topologies right. I assume there are no such issues on s390x, so that
> >>> the vCPU to CPUState mapping could stay 1:1?
> >>
> >> s390 hardware today already has a topology and CPU features.  We are not 
> >> modelling it in QEMU right now, but want to go there in the future so that 
> >> there would be no simple 1:1 mapping anymore.
> > 
> > In that case please enlighten us how the topology model should/could
> > look like in the future, so that we can align this with the x86
> > remodelling and APIC/ID discussion.
> 
> Current models provide topology information via the STSI instruction
> (http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf
> see page 10-134 and following) function code 15. The system basically informs 
> about
> cpus and containers, which boils down to how the hardware is organized:
> 
> e.g. fr zec12 we have up to 4 Nodes(aka books). A book contains one MCM
> with 6 processors. Each processor then has 6 cores.
> (see http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf)
> 
> Future systems might look different, I dont know if and how the topology will
> change. Currently there is no information about memory locality, only 
> processor
> grouping.
> 
> As Jens said, as of now we do not provide any topology information to the
> guest, but we might to change that in the future.
> 
> I havent followed the x86 discussion, so please let me know if that
> doesnt answer your question.

The x86 solution involves adding a "cpu-add" QMP command by now because
we don't have all that's necessary to make device_add work on x86 but we
want to have CPU hotplug in QEMU 1.5.

But in the case of s390 it may be feasible to make device_add work at
the lowest level (CPU core?) (with no topology setting features, because
you still don't have it), and later you can consider adding objects to
represent books, MCM, processors, cores, etc. That's the long-term plan
for x86: having new classes and objects for CPU sockets/cores/threads.

You could even translate cpu-add to the equivalent of a device_add
command, if you want to make the cpu-add command work on s390 too.

Later we may try to agree on a common target-independent device tree
layout so we can have a target-independent topology-aware CPU hotplug
interface. Or we could simply allow each architecture to use a different
device tree layout to represent CPU topology.

-- 
Eduardo