Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs

[David Hildenbrand]

> Am 10.02.2016 um 16:28 schrieb David Hildenbrand:
> > For x86, cpu models are realized by making x86_64-cpu an abstract class and
> > creating loads of new classes, e.g. host-x86_64-cpu or haswell-x86_64-cpu.
> > 
> > How does 'device_add ' play together with the x86 cpu model
> > approach? And with cpu models specified via "-cpu" in general?  
> 
> device_add needs to use an instantiatable type, like the ones you sketch
> above.
> 
> > Or does that in return mean, that "making models own classes" is outdated? 
> > Or
> > will some internal conversion happen that I am missing?
> > 
> > What is the plan for cpu models and cpu hotplug? How are cpu models to be
> > defined in the future?  
> 
> Someone at IBM was working on defining models for s390x - not sure what
> the status is?

That one is me right now :) Michael Mueller was working on a version without
explicit features last year. I'm now looking into models with features that can
be turned on/off - like x86 has.

As I'm trying to get a view of the bigger picture I also have to take care of
cpu hotplug, and I am not quite sure yet if we (s390) really want or need a
device_add.

a) Specification of cpu model and cpu hotplug on QEMU start

-smp 2,maxcpus=6 -cpu zBC12,+feata,+featb,prop=value

Here, it is quite clear that all cpus will get the same feature set. We don't
need any information about internals (e.g. which class is used internally for
the cpu)

b) Adding cpus via the monitor "cpu_add"

cpu-add id=3

Quite easy, we get what we ordered when starting QEMU, a cpu just like the
others.

c) Adding a cpu via device_add

device_add s390-cpu,id=3
-> Not uniform. We _want_ cpu models as cpu subclasses
(http://wiki.qemu.org/Features/CPUHotplug)

OR

device_add zBC12-s390-cpu,id=3
-> Not uniform. We don't specify the properties. But we have to specify some
magic class that we didn't have to specify on the command line. Implicitly
used information for a device.

OR

device_add zBC12-s390-cpu,id=3,feata=on,featb=off,prop=value
-> Fully specified. Again. And we need information about the internally used
class. Implicitly used information for a device.

Especially the last two examples are bad:
1) We could hotplug _different_ cpus, which is absolutely not what we want on
s390.
2) In every sane setup, we have to respecify what we already setup up at QEMU
start. (and I don't see any benefit)
3) Interface that is much more complex and more error prone to use.


d) Benefits of the new interface.

Unfortunately I can't seem to find any
(http://wiki.qemu.org/Features/CPUHotplug) but what I can think of

1) Specify something like topology more detailed (IMHO not applicable for s390)
2) Do a device_del (IMHO not applicable for s390)


Both of these points could easily be realized by extending the existing cpu-add
and by introducing a cpu_del (if really needed).


I am not against this, I just want to understand what the plan is. Because this
highly overcomplicates matter for us (s390) and requires yet another interface
to be maintained (I have some quote about new interfaces in the back of my hand
from some Linus guy ;) )

"Targets are encouraged to (re)design CPU creation so that it would be possible
to use device_add/device-del interface for it. However if due to target
design or a necessary long re-factoring time to use CPU with
device_add/device-del interface, it is possible speed-up CPU hot-add feature
development by using cpu-add interface."
(http://wiki.qemu.org/Features/CPUHotplug)

If nobody can convince me that this is the way to go and everything I said is
already clear or wrong, then I'd vote for keeping it simple and using cpu-add.

David

Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs

[David Hildenbrand]

> Changes from v2->v3:
> 
> * Call cpu_remove_sync rather than cpu_remove().
> * Pull latest version of patches from pseries set (v6).  Trivial change to 
>   "Reclaim VCPU objects" to fix checkpatch error.
> * Add object_unparent during s390_cpu_release to accomodate changes in 
>   Patch 4 "Reclaim VCPU objects."
> * Remove a cleanup patch in favor of 2 patches from pseries set.
> 
> **
> 
> The following patchset enables hotplug of s390 CPUs.
> 
> The standard interface is used -- to configure a guest with 2 CPUs online at 
> boot and 4 maximum:
> 
> qemu -smp 2,maxcpus=4
> 
> To subsequently hotplug a CPU:
> 
> Issue 'device_add s390-cpu,id=' from monitor.

(questions for the bigger audience)

For x86, cpu models are realized by making x86_64-cpu an abstract class and
creating loads of new classes, e.g. host-x86_64-cpu or haswell-x86_64-cpu.

How does 'device_add ' play together with the x86 cpu model
approach? And with cpu models specified via "-cpu" in general?

Or does that in return mean, that "making models own classes" is outdated? Or
will some internal conversion happen that I am missing?

What is the plan for cpu models and cpu hotplug? How are cpu models to be
defined in the future?

David

Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs

[Andreas Färber]

Am 10.02.2016 um 16:28 schrieb David Hildenbrand:
> For x86, cpu models are realized by making x86_64-cpu an abstract class and
> creating loads of new classes, e.g. host-x86_64-cpu or haswell-x86_64-cpu.
> 
> How does 'device_add ' play together with the x86 cpu model
> approach? And with cpu models specified via "-cpu" in general?

device_add needs to use an instantiatable type, like the ones you sketch
above.

> Or does that in return mean, that "making models own classes" is outdated? Or
> will some internal conversion happen that I am missing?
> 
> What is the plan for cpu models and cpu hotplug? How are cpu models to be
> defined in the future?

Someone at IBM was working on defining models for s390x - not sure what
the status is?

Regards,
Andreas

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

Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs

[Christian Borntraeger]

On 01/27/2016 05:53 PM, Matthew Rosato wrote:
> Changes from v2->v3:
> 
> * Call cpu_remove_sync rather than cpu_remove().
> * Pull latest version of patches from pseries set (v6).  Trivial change to 
>   "Reclaim VCPU objects" to fix checkpatch error.
> * Add object_unparent during s390_cpu_release to accomodate changes in 
>   Patch 4 "Reclaim VCPU objects."
> * Remove a cleanup patch in favor of 2 patches from pseries set.
> 
> **
> 
> The following patchset enables hotplug of s390 CPUs.
> 
> The standard interface is used -- to configure a guest with 2 CPUs online at 
> boot and 4 maximum:
> 
> qemu -smp 2,maxcpus=4
> 
> To subsequently hotplug a CPU:
> 
> Issue 'device_add s390-cpu,id=' from monitor.
> 
> At this point, the guest must bring the CPU online for use -- This can be 
> achieved via "echo 1 > /sys/devices/system/cpu/cpuX/online" or via a 
> management 
> tool like cpuplugd.
> 
> Hot unplug support is provided via 'device_del ', however s390 does not 
> have
> a mechanism for gracefully handling a CPU that has been removed, so this event
> triggers a reset of the guest in order to force recognition.  
> 
> This patch set is based on work previously done by Jason Herne.
> 
> Bharata B Rao (3):
>   exec: Remove cpu from cpus list during cpu_exec_exit()
>   exec: Do vmstate unregistration from cpu_exec_exit()
>   cpu: Add a sync version of cpu_remove()
> 
> Gu Zheng (1):
>   cpu: Reclaim vCPU objects
> 
> Matthew Rosato (6):
>   s390x/cpu: Cleanup init in preparation for hotplug
>   s390x/cpu: Set initial CPU state in common routine
>   s390x/cpu: Move some CPU initialization into realize
>   s390x/cpu: Add functions to (un)register CPU state
>   s390/virtio-ccw: Add hotplug handler and prepare for unplug
>   s390x/cpu: Allow hot plug/unplug of CPUs
> 
>  cpus.c | 50 +
>  exec.c | 30 
>  hw/s390x/s390-virtio-ccw.c | 30 +++-
>  hw/s390x/s390-virtio.c | 64 +++---
>  hw/s390x/s390-virtio.h |  2 +-
>  include/qom/cpu.h  | 18 
>  include/sysemu/kvm.h   |  1 +
>  kvm-all.c  | 57 -
>  kvm-stub.c |  5 
>  target-s390x/cpu.c | 70 
> +++---
>  target-s390x/cpu.h |  4 +++
>  11 files changed, 308 insertions(+), 23 deletions(-)


Acked-by: Christian Borntraeger 


Alexander, if you are too busy at the moment, we could carry
these patches via the s390/kvm tree?

We want these patches merged, since we have to libvirt as well to
use device_add instead of cpu_add (sigh).

Christian

[Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs

[Matthew Rosato]

Changes from v2->v3:

* Call cpu_remove_sync rather than cpu_remove().
* Pull latest version of patches from pseries set (v6).  Trivial change to 
  "Reclaim VCPU objects" to fix checkpatch error.
* Add object_unparent during s390_cpu_release to accomodate changes in 
  Patch 4 "Reclaim VCPU objects."
* Remove a cleanup patch in favor of 2 patches from pseries set.

**

The following patchset enables hotplug of s390 CPUs.

The standard interface is used -- to configure a guest with 2 CPUs online at 
boot and 4 maximum:

qemu -smp 2,maxcpus=4

To subsequently hotplug a CPU:

Issue 'device_add s390-cpu,id=' from monitor.

At this point, the guest must bring the CPU online for use -- This can be 
achieved via "echo 1 > /sys/devices/system/cpu/cpuX/online" or via a management 
tool like cpuplugd.

Hot unplug support is provided via 'device_del ', however s390 does not have
a mechanism for gracefully handling a CPU that has been removed, so this event
triggers a reset of the guest in order to force recognition.  

This patch set is based on work previously done by Jason Herne.

Bharata B Rao (3):
  exec: Remove cpu from cpus list during cpu_exec_exit()
  exec: Do vmstate unregistration from cpu_exec_exit()
  cpu: Add a sync version of cpu_remove()

Gu Zheng (1):
  cpu: Reclaim vCPU objects

Matthew Rosato (6):
  s390x/cpu: Cleanup init in preparation for hotplug
  s390x/cpu: Set initial CPU state in common routine
  s390x/cpu: Move some CPU initialization into realize
  s390x/cpu: Add functions to (un)register CPU state
  s390/virtio-ccw: Add hotplug handler and prepare for unplug
  s390x/cpu: Allow hot plug/unplug of CPUs

 cpus.c | 50 +
 exec.c | 30 
 hw/s390x/s390-virtio-ccw.c | 30 +++-
 hw/s390x/s390-virtio.c | 64 +++---
 hw/s390x/s390-virtio.h |  2 +-
 include/qom/cpu.h  | 18 
 include/sysemu/kvm.h   |  1 +
 kvm-all.c  | 57 -
 kvm-stub.c |  5 
 target-s390x/cpu.c | 70 +++---
 target-s390x/cpu.h |  4 +++
 11 files changed, 308 insertions(+), 23 deletions(-)

-- 
1.9.1