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

Re: [PATCH 4/8] x86/spec-ctrl: Extend all SPEC_CTRL_{ENTER,EXIT}_* comments



On 15/09/2023 8:07 am, Jan Beulich wrote:
> On 14.09.2023 21:23, Andrew Cooper wrote:
>> On 14/09/2023 8:58 am, Jan Beulich wrote:
>>> On 13.09.2023 22:27, Andrew Cooper wrote:
>>>> @@ -319,7 +334,14 @@ UNLIKELY_DISPATCH_LABEL(\@_serialise):
>>>>      UNLIKELY_END(\@_serialise)
>>>>  .endm
>>>>  
>>>> -/* Use when exiting to Xen in IST context. */
>>>> +/*
>>>> + * Use when exiting from any entry context, back to Xen context.  This
>>>> + * includes returning to other SPEC_CTRL_{ENTRY,EXIT}_* regions with
>>>> + * unsanitised state.
>>>> + *
>>>> + * Because we might have interrupted Xen beyond SPEC_CTRL_EXIT_TO_$GUEST, 
>>>> we
>>>> + * must treat this as if it were an EXIT_TO_$GUEST case too.
>>>> + */
>>>>  .macro SPEC_CTRL_EXIT_TO_XEN
>>>>  /*
>>>>   * Requires %rbx=stack_end
>>> Is it really "must"? At least in theory there are ways to recognize that
>>> exit is back to Xen context outside of interrupted entry/exit regions
>>> (simply by evaluating how far below stack top %rsp is).
>> Yes, it is must - it's about how Xen behaves right now, not about some
>> theoretical future with different tracking mechanism.
> Well, deleting "must" does exactly that

Nonsense.

*When* someone changes the logic such that there's an alternative route,
the comment necessarily needs updating.  And until that point, the logic
*must* behave in this way to be correct.

~Andrew



 


Rackspace

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