[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: log XPTI enabled status

On 01/02/18 13:18, Jan Beulich wrote:
>>>> On 01.02.18 at 13:29, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 01/02/18 08:52, Jan Beulich wrote:
>>> At the same time also report the state of the two defined
>>> ARCH_CAPABILITIES MSR bits (but don't expose the MSR to guests yet).
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> ---
>>> Should we disable XPTI right here when we find RDCL_NO?
>> I was planning to wait for a working piece of hardware before trying to
>> implement ARCH_CAPS, given how often the spec changed.  Then again, at
>> the point Linux is doing this, we might as well consider it safe.
> I have no idea how far Linux has progressed in that direction, so I
> can't decide whether this is a "yes" or a "let's better wait".

It will probably be fine to implement RDCL_NO.

I definitely don't want to see about implementing the IBRS_ATT without
having a real implementation, because that is going to be complicated to
make work beside the current logic.

>>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>>> @@ -244,6 +244,7 @@ XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /
>>>  XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation 
>>> Single Precision */
>>>  XEN_CPUFEATURE(IBRSB,         9*32+26) /*A  IBRS and IBPB support (used by 
>>> Intel) */
>>>  XEN_CPUFEATURE(STIBP,         9*32+27) /*A! STIBP */
>> This doesn't appear to be used?
> See the conditional around rdmsrl(MSR_ARCH_CAPABILITIES, caps).

Ah, in which case you should introduce the CPUID bit for this MSR.  It
is next to STIBP and architecturally specified.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.