When decoding CPUID data to virCPUDef we need to be careful about using
a CPU model which cannot be directly used on the current host. Normally,
libvirt would notice the features which prevent the model from being
usable and it would disable them in the computed virCPUDef, but this
won't work in case the definition of the CPU model in QEMU contains more
features than what we have in cpu_map.xml. We need to count with the
usability blockers we got from QEMU and explicitly disable all of them
to make the computed virCPUDef usable.

https://bugzilla.redhat.com/show_bug.cgi?id=1464832

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
---
 src/cpu/cpu_x86.c | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index e197e31310..0dbc17f199 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -627,7 +627,8 @@ x86DataAddSignature(virCPUx86Data *data,
 static virCPUDefPtr
 x86DataToCPU(const virCPUx86Data *data,
              virCPUx86ModelPtr model,
-             virCPUx86MapPtr map)
+             virCPUx86MapPtr map,
+             virDomainCapsCPUModelPtr hvModel)
 {
     virCPUDefPtr cpu;
     virCPUx86Data copy = VIR_CPU_X86_DATA_INIT;
@@ -647,6 +648,21 @@ x86DataToCPU(const virCPUx86Data *data,
     x86DataSubtract(&copy, &modelData);
     x86DataSubtract(&modelData, data);
 
+    /* The hypervisor's version of the CPU model (hvModel) may contain
+     * additional features which may be currently unavailable. Such features
+     * block usage of the CPU model and we need to explicitly disable them.
+     */
+    if (hvModel && hvModel->blockers) {
+        char **blocker;
+        virCPUx86FeaturePtr feature;
+
+        for (blocker = hvModel->blockers; *blocker; blocker++) {
+            if ((feature = x86FeatureFind(map, *blocker)) &&
+                !x86DataIsSubset(&copy, &feature->data))
+                x86DataAdd(&modelData, &feature->data);
+        }
+    }
+
     /* because feature policy is ignored for host CPU */
     cpu->type = VIR_CPU_TYPE_GUEST;
 
@@ -1835,6 +1851,7 @@ x86Decode(virCPUDefPtr cpu,
     virCPUx86Data copy = VIR_CPU_X86_DATA_INIT;
     virCPUx86Data features = VIR_CPU_X86_DATA_INIT;
     virCPUx86VendorPtr vendor;
+    virDomainCapsCPUModelPtr hvModel;
     uint32_t signature;
     ssize_t i;
     int rc;
@@ -1855,7 +1872,7 @@ x86Decode(virCPUDefPtr cpu,
      */
     for (i = map->nmodels - 1; i >= 0; i--) {
         candidate = map->models[i];
-        if (!virCPUModelIsAllowed(candidate->name, models, NULL)) {
+        if (!virCPUModelIsAllowed(candidate->name, models, &hvModel)) {
             if (preferred && STREQ(candidate->name, preferred)) {
                 if (cpu->fallback != VIR_CPU_FALLBACK_ALLOW) {
                     virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
@@ -1883,7 +1900,7 @@ x86Decode(virCPUDefPtr cpu,
             continue;
         }
 
-        if (!(cpuCandidate = x86DataToCPU(&data, candidate, map)))
+        if (!(cpuCandidate = x86DataToCPU(&data, candidate, map, hvModel)))
             goto cleanup;
         cpuCandidate->type = cpu->type;
 
-- 
2.14.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 10/04/2017 10:58 AM, Jiri Denemark wrote:
> When decoding CPUID data to virCPUDef we need to be careful about using
> a CPU model which cannot be directly used on the current host. Normally,
> libvirt would notice the features which prevent the model from being
> usable and it would disable them in the computed virCPUDef, but this
> won't work in case the definition of the CPU model in QEMU contains more
> features than what we have in cpu_map.xml. We need to count with the
> usability blockers we got from QEMU and explicitly disable all of them
> to make the computed virCPUDef usable.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1464832
> 
> Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
> ---
>  src/cpu/cpu_x86.c | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
> 

Reviewed-by: John Ferlan <jferlan@redhat.com>

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list