Re: [Xen-devel] [PATCH v6.5 19/26] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD}

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.01.18 at 13:03, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 04/01/18 09:52, Jan Beulich wrote:
>>
>>> --- a/xen/arch/x86/msr.c
>>> +++ b/xen/arch/x86/msr.c
>>> @@ -132,7 +132,8 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
>>> uint64_t *val)
>>>      case MSR_SPEC_CTRL:
>>>          if ( !cp->feat.ibrsb )
>>>              goto gp_fault;
>>> -        *val = vp->spec_ctrl.guest;
>>> +        *val = (vp->spec_ctrl.direct_access
>>> +                ? vp->spec_ctrl.host : vp->spec_ctrl.guest);
>>>          break;
>> To recap, I had asked whether this is valid ahead of later changes,
>> which you replied to saying this won't have any "by not permitting
>> the guest any access until patch 25". In which case at the very
>> least the patch title is misleading. Yet I don't even agree with what
>> you say - patch 25 only fiddles with CPUID bits. Did you perhaps
>> mean to say "By not permitting a well behaved guest any access
>> until patch 25," as one trying to access the MSRs without consulting
>> the CPUID bits would be able to starting with the patch here aiui?
> 
> The guest access bit being clear in cpufeatureset.h means that the
> maximum featureset calculations for guests will guarantee that
> cp->feat.ibrsb is currently false.

Well, that was the point of my reply: You mean well behaved
guests (ones consulting CPUID), but you don't say so, and - as
said - I think ones trying to access the MSRs anyway will observe
the accesses to work as of this patch, yet as it seems not fully
correctly (until that later patch is in place).

As pointed out before - I fine with things not working fully right
until that later patch, but the situation should be stated clearly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel