Hi David, On Wed, 2019-03-27 at 16:46 +0100, 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 Yes I would assume so. > > > I guess there will be quite some issues to be sorted out. > That's what I'm getting from the several feedback I got so far. But the more fundamental question is about the need for it. If you think this goes in the right direction to make things more generic and architecture agnostic, it might be worth the effort of trying to design such solution. If instead you think this will be reinventing the wheel and will not benefit any use case, then let's not waste some time on this. Thanks, Sebastien
