On Mon, Dec 14, 2015 at 10:47:26AM -0600, Andrew Jones wrote:
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?
We do pass some options, for example, you can restrict the GIC to v2: https://libvirt.org/formatdomain.html#elementsFeatures That could be modified to work for your purpose IIUC, right?
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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list