On 19/01/18 10:45, Jan Beulich wrote: >>>> On 18.01.18 at 16:46, <[email protected]> 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
