[libvirt] [PATCH v2] qemu: Add check for whether KVM nesting is enabled

Andrea Bolognani abologna at redhat.com
Tue Nov 27 17:05:34 UTC 2018


On Mon, 2018-11-26 at 18:38 -0500, John Ferlan wrote:
[...]
> +static bool
> +virQEMUCapsKVMIsNested(void)
> +{
> +    VIR_AUTOFREE(char *) kConfig = NULL;
> +
> +    /* Intel, AMD, and s390 related checks */
> +    if ((kConfig = virKModConfig()) &&
> +        (strstr(kConfig, "kvm_intel nested=1") ||
> +         strstr(kConfig, "kvm_amd nested=1") ||
> +         strstr(kConfig, "kvm nested=1")))
> +        return true;
> +    return false;
> +}

I might be doing it wrong, but I'm pretty sure I've enabled nested
virtualization properly on my laptop given that I can successfully
run 'modprobe kvm_intel' inside the L1 guest, and yet I get

  # modprobe -c | grep -c nested=1
  0

both in the L0 host and the L1 guest, so this check doesn't seem
accurate to me.

Oh, wait, I get it now: 'modprobe -c' doesn't dump the *current* host
configuration, but the *static* one! So if you enable nested KVM
support by doing

  # modprobe -r kvm_intel
  # modprobe kvm_intel nested=1

like I did, then the check above will not report it as enabled even
though it is; conversely, if you drop the appropriate config snippet
in /etc/modprobe.d/ but don't reload the module it will report it as
enabled even though it's not!

As an added bonus, if you have random whitespace or additional
options in the configuration line for the module, both of which are
completely legal, then the string matching will fail :)

We will probably also need to add a completely different check for
POWER9 hosts, where nested KVM support is enabled through a machine
type property of the L1 guest rather than a setting on the host.
I'll look into that as soon as I can get my hands on some suitable
hardware.

One final remark about the naming: <kvmIsNested/> seems wrong to me,
as IIUC it's not part of the capabilities of the L1 guest (where
KVM is, indeed, nested) but rather of the L0 host, which makes
<kvmSupportsNesting/> or something like that a much better choice
in my opinion.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list