Experimentally, the behaviour of reserved bits in MSR_PRED_CMD changed between
beta and production microcode, and now raises a #GP fault for set reserved
bits. The AMD spec for future hardware also specifies this behaviour, and it
is the more sensible behaviour to implement.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
x86/msr: further correct the emulation behaviour of MSR_PRED_CMD
Following commit
a6aa678fa3 ("x86/msr: Correct the emulation behaviour
of MSR_PRED_CMD") we may end up writing the low bit with the wrong
value. While it's unlikely for a guest to want to write zero there, we
should still permit (this without incurring the overhead of an actual
barrier). Correcting this right away will also help whenever further
bits in the MSR might become defined.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit:
a6aa678fa380e9369cc44701a181142322b3a4b0
master date: 2018-04-16 13:18:19 +0100
master commit:
a996273d1fc10d14598985703227bfa35a91f681
master date: 2018-04-18 11:16:37 +0200
if ( !cp->feat.ibrsb && !cp->extd.ibpb )
goto gp_fault; /* MSR available? */
- /*
- * The only defined behaviour is when writing PRED_CMD_IBPB. In
- * practice, real hardware accepts any value without faulting.
- */
- if ( v == curr && (val & PRED_CMD_IBPB) )
- wrmsrl(MSR_PRED_CMD, PRED_CMD_IBPB);
+ if ( val & ~PRED_CMD_IBPB )
+ goto gp_fault; /* Rsvd bit set? */
+
+ if ( v == curr )
+ wrmsrl(MSR_PRED_CMD, val);
break;
case MSR_INTEL_MISC_FEATURES_ENABLES: