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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
