On 12/13/18 8:29 AM, Michal Privoznik wrote: > On 11/29/18 2:55 AM, John Ferlan wrote: >> Support for nested KVM is handled via a kernel module configuration >> parameters values for kvm_intel, kvm_amd, kvm_hv (PPC), or kvm (s390). >> While it's possible to fetch the kmod config values via virKModConfig, >> unfortunately that is the static value and we need to get the >> current/dynamic value from the kernel file system. >> >> So this patch adds a new API virHostKVMSupportsNesting that will >> search the 3 kernel modules to get the nesting value and check if >> it is 'Y' (or 'y' just in case) or '1' to return a true/false whether >> the KVM kernel supports nesting. >> >> We need to do this in order to handle cases where adjustments to >> the value are made after libvirtd is started to force a refetch of >> the latest QEMU capabilities since the correct CPU settings need >> to be made for a guest to add the "vmx=on" to/for the guest config. > > Ah, so if nested KVM is not enabled that qemu might report vmx:false and > if it is enabled it reports vmx:true? > Right... If I followed the breadcrumbs in the bz (private/locked 1645139) the kernel parameter was changed after libvirtd was started. Then a L0 guest was created using virt-manager and started. When looking at that guest the 'vmx' was not on, thus no nesting allowed. Even restarting libvirtd didn't help because none of the conditions used to determine whether we should re-read the capabilities was present. Only after clearing the capabilities cache did the "proper" thing happen (see comment 14 in the bz - thanks to Pavel for the details - I'm not sure I would have come up with that given the details I saw in the case). John > ACK in that case. > > Michal > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
