File 5af97999-viridian-cpuid-leaf-40000003.patch of Package xen.openSUSE_Leap_42.3_Update

Overview Repositories Revisions Requests Users Attributes Meta

File 5af97999-viridian-cpuid-leaf-40000003.patch of Package xen.openSUSE_Leap_42.3_Update

# Commit 29fc0493d8eabdd63f5bbff9e3069253053addca
# Date 2018-05-14 12:57:13 +0100
# Author Paul Durrant <paul.durrant@citrix.com>
# Committer Andrew Cooper <andrew.cooper3@citrix.com>
viridian: fix cpuid leaf 0x40000003

The response to viridian leaf 3 needs to split a 64-bit mask across EAX and
EBX, with the low order 32 bits in EAX and the high order 32 bits in EBX.
To facilitate this a union of two uint32_t values and the mask (type
HV_PARTITION_PRIVILEGE_MASK) is allocated on stack as follows:

union {
    HV_PARTITION_PRIVILEGE_MASK mask;
    uint32_t lo, hi;
} u;

This, of course, is incorrect as both lo and hi will alias the low order
32 bits of the mask.

This patch wraps lo and hi in an anonmymous struct to achieve the desired
effect.

NOTE: Fixing this also stops Windows making the HvGetPartitionId hypercall
      which was previously considered erroneous behaviour. Thus the
      hypercall handler is also modified to stop squashing the
      'unimplemented' warning for this hypercall.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -245,7 +245,7 @@ void cpuid_viridian_leaves(const struct
         };
         union {
             HV_PARTITION_PRIVILEGE_MASK mask;
-            uint32_t lo, hi;
+            struct { uint32_t lo, hi; };
         } u;
 
         if ( !(viridian_feature_mask(d) & HVMPV_no_freq) )
@@ -966,12 +966,10 @@ int viridian_hypercall(struct cpu_user_r
         gprintk(XENLOG_WARNING, "unimplemented hypercall %04x\n",
                 input.call_code);
         /* Fallthrough. */
-    case HvGetPartitionId:
     case HvExtCallQueryCapabilities:
         /*
-         * These hypercalls seem to be erroneously issued by Windows
-         * despite neither AccessPartitionId nor EnableExtendedHypercalls
-         * being set in CPUID leaf 2.
+         * This hypercall seems to be erroneously issued by Windows
+         * despite EnableExtendedHypercalls not being set in CPUID leaf 2.
          * Given that return a status of 'invalid code' has not so far
          * caused any problems it's not worth logging.
          */

Places

File 5af97999-viridian-cpuid-leaf-40000003.patch of Package xen.openSUSE_Leap_42.3_Update

Places