[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs |
Date: |
Wed, 10 Feb 2016 16:28:43 +0100 |
> 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=<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 <cpu class>' 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