[libvirt-users] Usable and non-usable CPU models in nested virtualization

[Jiri Denemark]

On Fri, Dec 07, 2018 at 11:52:38 +0100, Milan Zamazal wrote:
> Hi, some custom CPU models are reported from
> virConnectGetDomainCapabilities as usable='yes' on a physical machine
> while as usable='no' inside a VM running on the same machine.  That's
> not completely surprising.
> 
> But what surprises me is that those models are still reported from
> virConnectCompareCPU as supported (VIR_CPU_COMPARE_SUPERSET) in the

virConnectCompareCPU uses CPUID data for comparison, which is not the
same as a list of features QEMU/KVM can provide on the host. You should
use virConnectCompareHypervisorCPU to check whether a given CPU can be
used on the host.

> nested environment and VMs can be started happily with them.
> 
> For instance, virConnectGetDomainCapabilities reports
> 
>   <model usable='no'>Skylake-Client</model>
> 
> but when I try to use that model anyway, the VM starts fine with it:
> 
>   <cpu mode='custom' match='exact' check='full'>
>     <model fallback='forbid'>Skylake-Client</model>
>     <topology sockets='16' cores='1' threads='1'/>
>     <feature policy='require' name='hypervisor'/>
>     <feature policy='disable' name='invpcid'/>

This is not the same as Skylake-Client, it's Skylake-Client without
invpcid. The usable='no' attribute says the Skylake-Client CPU model is
not usable unless you disable some features. You did that and it works.
If you asked for just Skylake-Client without any <feature> element, the
domain should fail to start.

Actually QEMU even reports what features need to be disabled to run each
CPU model, but I don't think that's really useful. You don't want to
disable all of them mechanically anyway since that can result in strange
CPU models which would confuse guests. That's why we only report the
usable=yes/no attribute.

Jirka