>>> On 24.05.18 at 12:13, <andrew.coop...@citrix.com> wrote: > 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.
See how 3dNow insns have disappeared? CPUID flags exist for the very purpose of allowing pieces to exist / not exist independent of one another. For the case here, just consider the case of Intel finding that some of their micro-architecture is vulnerable to v4 but not v2. Why would they add IBRSB to the respective microcode, when all they'd need there is SSBD? (Of course, leaving aside the consideration that they had specified such a dependency themselves, and iirc they still do to at least some degree.) Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
