Re: [libvirt] ARM KVM GICv3 Support
On Mon, Dec 14, 2015 at 12:31:59PM +0100, Christoffer Dall wrote:
Hi all,
I'm trying to figure out what the correct solution for libvirt support
for ARM KVM guests with GICv3 is.
The challenge is that QEMU's virt machine model defaults to GICv2 unless
you specify an additional "-machine gic-version=host" parameter to QEMU,
in which case your VM gets the same GIC version as your host.
Now, I'm told that this is inconvenient for libvirt, because it
typically does not pass any -machine options, is that correct?
If that is correct, then my guess is that that's because it's used to
the qemu machine model automatically selecting appropriate defaults, and
for pc, due to versioning, there are several machine model types to
choose from. mach-virt hasn't started versioning yet.
Further, there are two additional complications: First, some guest
images may not include GICv3 support. For Linux, this is relatively old
kernels (prior to v3.17), but other guests may only support GICv2.
Second, some hardware platforms only support GICv2 guests, some only
support GICv3 guests, and some support both GICv2 and GICv3 guests
(those hosts with a GICv3 with the backwards compatibility support).
It is unclear to me how libvirt users will relate to these constraints.
For example, in an OpenStack deployment, will it somehow be easy to tell
which nodes support which GIC version such that administrators can
choose compatible VM images, or how does that work?
libvirt has the concept of capabilities that it can negotiate. I know
this is used heavily with x86 cpu features that some guests depend on.
I think a guest dependency on gic version could fit here.
The end goal here is to determine if we need to add any functionality to
QEMU to better support libvirt, and what kind of features/glue need to
be added to libvirt for this to work.
I've been starting to wonder if we should consider breaking mach-virt
into multiple types. For example, one that focuses on big, enterprise-y
type configs (only 64-bit guests, only virtio-pci, extending the size
of main memory beyond 30G, for sure, and possibly even moving the
PCIE_MMIO_HIGH mapping to extend beyond 511G. It'd even be good to
remap the redistributor space to get more than 123 vcpus.
Making new mach-virt types and versioning those types would probably
avoid needing much libvirt changes, but teaching libvirt (if it doesn't
know already) how to manage machine parameters to effectively create new
types as needed, also sounds good to me.
Thanks,
drew