Re: [PATCH 6/6] x86/boot: Expose MSR_ARCH_CAPS data in guest max policies

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/05/2023 8:31 am, Jan Beulich wrote:
> On 19.05.2023 17:52, Andrew Cooper wrote:
>> On 17/05/2023 10:20 am, Jan Beulich wrote:
>>> On 16.05.2023 21:31, Andrew Cooper wrote:
>>>> On 16/05/2023 3:53 pm, Jan Beulich wrote:
>>>>> I guess that's no
>>>>> different from other max-only features with dependents, but I wonder
>>>>> whether that's good behavior.
>>>> It's not really something you get a choice over.
>>>>
>>>> Default is always less than max, so however you choose to express these
>>>> concepts, when you're opting-in you're always having to put information
>>>> back in which was previously stripped out.
>>> But my point is towards the amount of data you need to specify manually.
>>> I would find it quite helpful if default-on sub-features became available
>>> automatically once the top-level feature was turned on. I guess so far
>>> we don't have many such cases, but here you add a whole bunch.
>> I'm not suggesting specifying it manually.  That would be a dumb UX move.
>>
>> But you absolutely cannot have "user turns on EIBRS" meaning "turn on
>> ARCH_CAPS too", because a) that requires creating the reverse feature
>> map which is massively larger than the forward feature map, and b) it
>> creates a vulnerability in the guest, and c) it's ambiguous - e.g. what
>> does turning on a sub-mode of AVX-512 mean for sibling sub-modes?
> Feels like a misunderstanding at this point, because what you're describing
> above is not what I was referring to. Instead I was specifically referring
> to "cpuid=...,arch-caps" not having any effect beyond the turning on of the
> MSR itself (with all-zero content). This is even worse with libxl not even
> having a way right now to express something like "arch-caps=..." to enable
> some of the sub-features for guests.

We discussed this on the x86 call.  In summary:

Right now, arch-caps is off-by-default because it doesn't work safely or
nicely.  I'm working on safely first, and nicely will come second.

The end result of my work is going to have arch-caps active by default
and supported.  End users aren't going to in a position of needing to
specify cpuid="...,arch-caps" in their config files.

Fixing libxl's ability to specify the contents is something needing to
be done before we can say arch-caps is fully supported, because right
now it's the only way users of xl/libxl have for levelling a VM for migrate.

> To explicitly answer the AVX512 part of your reply: Turning on a sub-mode
> alone could be useful as well (with the effect of also turning on the
> main feature, and with or without [policy question] also turning on other
> default-on subfeatures of AVX512). But again - that direction of possible
> "implications" isn't what my earlier reply was about. As you say, reverse
> maps would then also be needed, whereas for what I'm suggesting only the
> deep-deps we already have are necessary: We'd grab the main feature's
> dependencies and AND that with the default mask before ORing into the
> domain's policy.

Having discussed this, I agree and specifically have an idea for how to
use it for AVX512.  But it is also going to take a fair amount of
rearranging in libxl/libxc to make work.

I.e., yes, but not immediately right now.

~Andrew