[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

(In fact, before this patch, a guest which poked at the MSRs wouldn't
find a #GP everywhere, because our MSR infrastructure is leaky.)


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.