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

[Igor Mammedov <imammedo@redhat.com>]

On Fri, 19 Apr 2013 15:16:36 +0200
Andreas Färber <afaerber@suse.de> wrote:

> Am 19.04.2013 09:51, schrieb Jens Freimann:
> > On Wed, Apr 17, 2013 at 08:06:37PM +0200, Andreas Färber wrote:
> >> Hi Jens,
> >>
> >> Am 03.04.2013 08:42, schrieb Jens Freimann:
> >>> this is what our approach to CPU hotplug looks like.
> >>> With respect to Igor's CPU hotplug series, how should we proceed? 
> >>> Should we change the interface to 
> >>> qemu_system_cpu_add_notifier/qemu_system_cpu_hotplug_request/cpu-add
> >>> etc?
> >>
> >> I am wondering if my recent qdev/device_add fixes would allow to
> >> implement CPU hot-add via device_add for s390x?
> > 
> > From what I've seen so far it could be possible, but...
> 
> Hm, so probably not a good idea? Just looking for a guinea pig for
> infrastructure testing...
Well it looks like good candidate for this, from what I saw though my
cursory review was that so far s390:
 1. it has only one CPU model, and 
 2. cpu_model string isn't at all
 3. no features are set externally (at least explicitly during CPU creation)

Once patches 1-8/16 from v4 cpu-add are in + Andreas patch for bussless
devices in device_add, generic infrastructure for device_add will be in place.
So new respin might be device_add based.

Perhaps there are missing pieces yet, but it would be easier to spot them
once trying implement stuff this way.

> 
> >> 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.

Let's discuss this not only between me and Eduardo.
Is short we propose to have generic numa topology interface that will be
accessible via QOM tree. Currently idea is to have tree that looks like:

/machine / node[0..x]/ socket[0..y] / core [0..z] / thread [0..n]
                                    |
                                    / thread [0..n]

where total amount of threads == max_cpus and the rest of nodes are calculated
using respective -smp options.

> 
> Regards,
> Andreas
>