Re: [Qemu-devel] Thoughts about introducing virtio-cpu

[Igor Mammedov]

On Wed, 27 Mar 2019 14:45:09 +0000
"Boeuf, Sebastien" <address@hidden> 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.
It was born mainly as the result of inability to deliver fine granularity
memory hotplug for guests that support memory hotplug with current kernel-mm
subsystem implementation. Ability to use virtio-mem on architectures that
do not have platform specific means to do hotplug is very useful but was
a nice side-effect.

It's still remains to see how much it will be able to deliver.
(I'm more interested in lessons it it will teach us in process).

> 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.
Current cpu hotplug (ACPI one) in QEMU is combination of both static
part describing what CPUs are possible on given instance and dynamic
that notifies when and which CPUs are present. Hardware impl. is
hidden behind ACPI so guest OS doesn't know about details and QEMU
is free to change interface when it's necessary without need for
matching guest OS update.

So what is the purpose of getting rid of ACPI and what you'd
gain from it?
What alternatives do you have in mind to describe hardware?

> 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