Re: [PATCH v2 3/3] x86/cpu-policy: Derive RSBA/RRSBA for guest policies

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.06.2023 17:38, Andrew Cooper wrote:
> On 02/06/2023 4:29 pm, Andrew Cooper wrote:
>> On 02/06/2023 11:20 am, Jan Beulich wrote:
>>> On 01.06.2023 16:48, Andrew Cooper wrote:
>>> What about a tool stack request leading to us setting the 2nd of the two
>>> bits here, while the other was already set? IOW wouldn't we better clear
>>> the other bit explicitly? (Due to the EIBRS dependency or RRSBA I think
>>> this can really only happen when the tool stack requests RSBA+EIBRS, as
>>> the deep deps clearing doesn't know the concept of "negative"
>>> dependencies.)
>> Hmm - I think there is a bug here, but it's not this simple.  I think
>> the only reasonable thing we can do is start rejecting bad input because
>> I don't think Xen can fix up safely.
>>
>> Xen must not ever clear RSBA, or we've potentially made the VM unsafe
>> behind the toolstack's back.
>>
>> If EIBRS != RRSBA, the toolstack has made a mistake.  Equally too for
>> RSBA && EIBRS.
>>
>> I think this is going to take more coffee to solve...
> 
> Actually, no.
> 
> I'm going to delete the hunk modifying recalculate_cpuid(), and move
> this patch back to the meaning it had in v1 which is just "get the
> policies looking correct".

Hmm, and how are you intending to achieve that goal without adjusting
behind the tool stack's back, and without it being an option (yet) to
reject the input? Iirc you agreed with my v1 remark that some fixing
that some fixing up is going to be necessary.

Since as you say (and as I should have realized when writing the earlier
reply) we may never clear RSBA, wouldn't it be an option to clear EIBRS
instead?

> It's still not supported for the toolstack to request ARCH_CAPS (the "a"
> marking), and the safely logic for that can come in a subsequent series
> along with the unit(ish) testing I was already planning to do.

Yet it not being supported doesn't mean we should leave a broken
result when we can fix things up (for the time being, i.e. until we
can report back that we don't like this feature combination).

Jan