On 05/23/2018 06:09 PM, Andrew Cooper wrote: > On 23/05/2018 22:59, Boris Ostrovsky wrote: >> On 05/23/2018 05:49 PM, Andrew Cooper wrote: >>> On 23/05/2018 22:40, Boris Ostrovsky wrote: >>>> Looking at vmx_cpuid_policy_changed(): >>>> >>>> >>>> if ( cp->feat.ibrsb ) >>>> vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); >>>> else >>>> vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); >>>> >>>> >>>> Is there a reason why we are not checking cp->feat.ssbd as well? >>> Yes. Read the final hunk of >>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9df52a25e0e95a0b9971aa2fc26c5c6a5cbdf4ef >> SSBD implies IBRS --- yes, that's true. But not the other way around, no? > That's not the way the dependency logic works. That hunk says "if you > haven't got IBRSB, then you don't have STIBP or SSBD either".
I guess my actual question is --- If you have IBRSB but not SSBD (which is what we have today), do we want to intercept the access and screen for the guest writing the SSBD bit? -boris > > It is, as documented, not completely strictly true (according to the > latest revision of the spec), but is there deliberately to simply so we > don't give the guest implausible configurations. There is not a > processor with STIBP but without IBRSB, nor is there one with SSBD > without STIBP or IBRSB, and it is unlikely that future processors would > change this arrangement. > > A side effect of prohibiting the implausible configurations is that the > logic in Xen is much more simple. > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
