On 23/05/2018 23:27, Boris Ostrovsky wrote: > 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?
What would that achieve in practice? TBF, I did start coding in the way you suggest, but came to the conclusion that it was a pointless waste. Conceptually, being able to use the SSBD bit even if you can't see it in CPUID is no different to "knowning" that certain instructions are implemented in the pipeline and using them anyway. Hiding the AES CPUID bit doesn't prevent the pipeline from executing the AES instructions if it encountered them. Furthermore, MSR_SPEC_CTRL is a frequently written MSR used in privilege entry/exit points - Intercepting slows your VM down massively. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
