Hi Christian, On Mon, 2019-04-01 at 13:57 +0200, Christian Borntraeger wrote: > > 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. Any pointer to this prototype? > > > 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. I understand it would not be easy, but it is okay if the idea is approved and supported by the community as they see this solution as a generic way to handle the complex CPU use case. That's why I'm looking for guidance here :) > This will also have a lot of churn in the guest operating > systems. Do you have some examples in mind? > > Is your main goal to avoid ACPI? Yes. In the context of supporting general hotplug (CPU/Memory/devices(PCI)), CPU is the last bit that will force us to use ACPI. > Thanks, Sebastien
