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 14:34, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 09/01/18 13:28, Jan Beulich wrote:
>>>>> 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.
> 
> But it still functions correctly.  A guest which ignores CPUID will
> still find two MSRs which unconditionally #GP when poked.  The logic to
> allow passthrough is also derived from the cpuid policy, which disallows
> the passthrough until patch 25.

Oh, right - I keep not realizing that the variable named "cp" is
the cpuid policy of the guest.

Jan


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