Re: Thoughts about introducing virtio-cpu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 

Thanks,

David / dhildenb



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux