On 24/05/18 09:13, Jan Beulich wrote: >>>> On 24.05.18 at 00:09, <andrew.coop...@citrix.com> wrote: >> 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. > As pointed out elsewhere I believe this is a wrong dependency to make, > even if perhaps current or past Intel docs suggest so (AMD ones don't > for their versions of the features). Wile it may be the case that there's > currently no case in practice with SSBD but no IBRSB, I don't see why > this would need to remain that way. The two things are strictly > independent.
Features will never disappear. x86, more than most, maintains its backwards compatibility. > I very much think there should be an indicator of the MSR itself > existing, set to the OR of any of the bits in the MSR that are valid. > Shouldn't such a mask anyway be part of struct msr_domain_policy > (as a companion to the current value of the MSR per vCPU)? The only think this gets you is the ability to create implausible combinations. I don't think it is a useful or sensible use of time trying to support combinations which will, most likely, never exist. Certainly not for combinations without a plausible usecase, as these will go stale very quickly, given the churn in this area. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
