Re: [Xen-devel] [PATCH v9 03/11] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/01/18 10:45, Jan Beulich wrote:
>>>> On 18.01.18 at 16:46, <andrew.cooper3@xxxxxxxxxx> wrote:
>> @@ -153,14 +168,44 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t 
>> val)
>>  {
>>      const struct vcpu *curr = current;
>>      struct domain *d = v->domain;
>> +    const struct cpuid_policy *cp = d->arch.cpuid;
>>      struct msr_domain_policy *dp = d->arch.msr;
>>      struct msr_vcpu_policy *vp = v->arch.msr;
>>  
>>      switch ( msr )
>>      {
>>      case MSR_INTEL_PLATFORM_INFO:
>> +    case MSR_ARCH_CAPABILITIES:
>> +        /* Read-only */
>>          goto gp_fault;
>>  
>> +    case MSR_SPEC_CTRL:
>> +        if ( !cp->feat.ibrsb )
>> +            goto gp_fault; /* MSR available? */
>> +
>> +        /*
>> +         * Note: SPEC_CTRL_STIBP is specified as safe to use (i.e. ignored)
>> +         * when STIBP isn't enumerated in hardware.
>> +         */
>> +
>> +        if ( val & ~(SPEC_CTRL_IBRS | SPEC_CTRL_STIBP) )
>> +            goto gp_fault; /* Rsvd bit set? */
>> +
>> +        vp->spec_ctrl.raw = val;
>> +        break;
> Did you check (or inquire) whether reading back the value on a
> system which ignores the write to 1 actually produces the
> written value? I'd sort of expect zero to come back instead.

Very good question.  I sadly don't having a suitable hardware/microcode
combination to experiment with at the moment.

Given that the point of ignoring the write to 1 was to make things
easier for virt/migration scenarios, I really hope the answer is "read
as written", rather than "read as zero".

CC'ing a bunch of people in the hopes that someone might have an answer.

~Andrew

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