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

Milan Zamazal mzamazal at redhat.com
Tue Dec 11 09:45:12 UTC 2018


Jiri Denemark <jdenemar at redhat.com> writes:

> 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.

Thank you for explanation.  However the behavior I observe is still not
clear to me.  The <cpu> snippet above is from a running domain,
successfully started from this definition:

  <cpu match="exact">
    <model>Skylake-Client</model>
    <topology cores="1" sockets="16" threads="1" />
    <numa>
        <cell cpus="0" id="0" memory="524288" />
    </numa>
  </cpu>

When this definition is fed to compare CPU, I get:

  # virsh hypervisor-cpu-compare cpu.xml
  CPU described in cpu.xml is incompatible with the CPU provided by hypervisor on the host

  # virsh cpu-compare cpu.xml
  Host CPU is a superset of CPU described in cpu.xml

It's not clear to me:

- Why is the domain successfully started despite hypervisor-cpu-compare
  rejects it?

- Why is `invpcid' disabled when `invpcid' is present in /proc/cpuinfo?

- What's the basic difference between virConnectCompareCPU and
  virConnectCompareHypervisorCPU?  Does "specific hypervisor and its
  abilities" (as stated in the documentation) mean that the hypervisor
  may extend CPU capabilities (by emulation), restrict CPU capabilities,
  or both (depending or particular feature etc.)?

> 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




More information about the libvirt-users mailing list