On 27.03.19 16:46, David Hildenbrand wrote: > On 27.03.19 15:45, Boeuf, Sebastien wrote: >> Hi everyone, >> >> I have recently learned about the on-going work from David Hildenbrand >> about virtio-mem, with a strong focus on proposing a unified solution >> for every architecture, which is the point of using paravirtualization >> here. >> This proposes a standardized way across different hypervisors to manage >> the guest RAM available, which at the same time will allow for a clean >> memory hot(un)plug support. >> >> Based on this, I was thinking that once this will be ready, and >> assuming you manage your devices through a PCI bus, the last bit to get >> rid of ACPI dependency would be about CPU. We could standardize the way >> vCPUs are created and managed by each hypervisors by introducing >> virtio-cpu. And the same way I mentioned architecture agnostic and >> clean hotplug for virtio-mem, I would expect this new virtio device to >> target the same goals. >> >> The end goal is to propose an approach where hypervisors could be >> unified across architectures, which would be convenient to support CPU >> hotplug features, without being forced to use ACPI only for this >> purpose. >> >> I am really looking for community's feedback here, as I would like to >> understand if there are some technical reasons why this approach would >> not be feasible/acceptable. Also, please let me know if there is >> already some on-going work, I'd be happy to participate! >> >> Thanks, >> Sebastien >> > > CCing MST, David G., Christian B., > > In general, on the QEMU side, CPUs are way more different between > architectures than e.g. blocks of memory we want to hot(un)plug > (virtio-mem). Especially different might be CPU topologies, but also > different kinds of IDs and how everything is setup/tear down in QEMU. > Then we have CPU features .... The SPAPR architecture which can plug > CPUs and COREs pops into my head. > > As I am most familiar with the s390x architecture: > > We have cpu hotplug support as part of the architecture (e.g. > interrupts), but no cpu unplug support. So for the purpose of real CPU > unplug, something like that would be required to get it working (without > HW or SCLP specification changes). > > What would it look like on the QEMU cmdline for s390x? > > -device virtio-cpu,model=qemu-s390x-cpu,core-id=1,id=cpu1 > > vs > > -device qemu-s390x-cpu,core-id=1,id=cpu1 > > device_del cpu1 > > > I guess there will be quite some issues to be sorted out. Claudio has a prototype for the sclp-based unplug, we just need to get this in the hands of the architects. Anyway, I think that CPUs really differ more than memory. We tried to get the cpu hotplug proper several years ago and it took quite a while to get this right for all kind of architectures. With that in mind, I guess that a virtio-cpu is probably far from easy. This will also have a lot of churn in the guest operating systems. Is your main goal to avoid ACPI?
