Re: [PATCH 18/24] XSM: make XSM hooks well-formed ones

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.08.2026 02:53, Daniel P. Smith wrote:
> On 7/28/26 9:22 AM, Jan Beulich wrote:
>> For whatever reason they didn't have an xsm_default_t first argument (to
>> cope with XSM=n mode), making it impossible to (easily) cover them in
>> xsm/hooks.h.
>>
>> flask_do_xsm_op() is also changed to return int, as all the function ever
>> returns is an int. This way no new machinery needs adding to xsm/hooks.h.
>> Instead one piece of compat machinery can then be dropped from
>> xsm/flask/flask_op.c.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> Instead of XSM_HOOK, using XSM_OTHER may also be a sensible option here.
> 
> I would say XSM_HOOK is sufficient since at this point it doesn't matter 
> what op is passed the dummy policy is just going to return the same 
> value. If the dummy policy is extended to support an op, then at that 
> point the implementer can switch it to XSM_OTHER.

Good.

>> Question is whether some/all of the other hooks still declared explicitly
>> in struct xsm_ops should follow suit.
> 
> I would say either comment these are exceptions or make them consistent, 
> though I haven't studied if there would be any consequences (doubtful) 
> changing the others.

As I've now added patches to convert the remaining hooks, this remark is
gone anyway. Hence comments there aren't going to be needed (unless those
extra patches would be rejected, once posted).

>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -439,7 +439,7 @@ static XSM_INLINE int xsm_hypfs_op(XSM_D
>>   
>>   #ifdef CONFIG_XSM
>>   
>> -static XSM_INLINE long xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
>> +static XSM_INLINE int xsm_do_xsm_op(XEN_GUEST_HANDLE_PARAM(void) op)
> 
> With this change, should there be a comment that the int is going to get 
> cast to long before return?

Not in my opinion, but if you strictly think such is needed, I can certainly
add a comment.

> Acked-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>

Thanks, including (again) for all the others. Nevertheless a request here:
Especially when an ack is the only part of a reply, could you please trim
reply context much like (most) others do? Without that, every reader has to
scroll through the entire reply context, just to find the single line at
the bottom. That can be a lot of scrolling with larger patches.

Jan