Re: MSR_SPEC_CTRL intercept

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 24/05/18 11:23, Jan Beulich wrote:
>>>> On 24.05.18 at 12:13, <andrew.cooper3@citrix.com> wrote:
>> On 24/05/18 09:13, Jan Beulich wrote:
>>>>>> On 24.05.18 at 00:09, <andrew.cooper3@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?

And LWIP, XOP (although XOP hasn't actually disappeared because it turns
out that Zen pipeline still execute FMA4 instruction).

> CPUID flags exist for the
> very purpose of allowing pieces to exist / not exist independent of
> one another.

Right, but you've picked examples that are independent of each other.

> 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?

Because all of these features centre around the same MSR.

The cores requiring SSBD are subset of those requiring IBRSB/STIBP, so
this doesn't matter in this specific case.

However, as already seen with IBRS and STIBP being a disjoin set, the
implementation is specifically to allow the unnecessary bits to function
as a compatible no-op, for virtualisation purposes.

So yes, the current behaviour specifically isn't as flexible as we could
be (under the latest revision of the spec), but it is specifically
called out out as a simplifying properly, with an explanation of why
this is a safe and sensible approach to take.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel