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

Re: [PATCH 01/24] XSM: reduce redundancy in hook machinery


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 30 Jul 2026 17:18:58 +0200
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:Content-Type:In-Reply-To:Autocrypt:From:Cc:Content-Language:References:To:Subject:User-Agent:MIME-Version:Date:Message-ID"
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 30 Jul 2026 15:19:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.07.2026 17:05, Daniel P. Smith wrote:
> On 7/28/26 9:13 AM, Jan Beulich wrote:
>> Hooks not taking xsm_default_t as first argument could of course be
>> adjusted to take one, at which point they could be covered here as well.
>> Question is why there is this difference in the first place.
> 
> I have a theory but I am not confident to write it down. I can see if I 
> can confirm with DDG if you really care that much to know the why. 
> Personally having a consistent hook interface convention would provide a 
> simpler pattern for people to follow if they are having to introdcue a 
> new hook.

Well, I don't really need to know the reason. If you agree that making
things uniform is a good move, I can simply stick a few more patches at
the end of this series.

>> .{alloc,free}_security_evtchns() and their dummy wrappers use struct
>> evtchn[] notation, while xsm_{alloc,free}_security_evtchns() use struct
>> evtchn *. Is there a reason for this inconsistency?
> 
> Person had one habit that was counter to Xen preference and missed one? 
> I have no justification for it. IMHO the interfaces should be kept 
> consistent to enable better grep-ability.

Which direction would you want it changed? Personally I like the []
notation better when arrays are meant, but the pointer notation will be
quite a bit easier with the new hooks.h machinery.

>> @@ -206,113 +117,57 @@ static inline void xsm_security_domainin
>>       alternative_vcall(xsm_ops.security_domaininfo, d, info);
>>   }
>>   
>> -static inline int xsm_domain_create(
>> -    xsm_default_t def, struct domain *d, uint32_t ssidref)
>> -{
>> -    return alternative_call(xsm_ops.domain_create, d, ssidref);
>> -}
>> +#define XSM_ALT_void alternative_vcall
>> +#define XSM_ALT_int  return alternative_call
>>   
>> -static inline int xsm_getdomaininfo(xsm_default_t def, struct domain *d)
>> -{
>> -    return alternative_call(xsm_ops.getdomaininfo, d);
>> +#define XSM_HOOK0(rtype, name) \
>> +static inline rtype xsm_ ## name(xsm_default_t def) \
>> +{ \
>> +    XSM_ALT_ ## rtype(xsm_ops.name); \
>>   }
>>   
>> -static inline int xsm_get_domain_state(xsm_default_t def, struct domain *d)
>> -{
>> -    return alternative_call(xsm_ops.get_domain_state, d);
>> +#define XSM_HOOK1(rtype, name, type1) \
>> +static inline rtype xsm_ ## name(xsm_default_t def, type1 arg1) \
>> +{ \
>> +    XSM_ALT_ ## rtype(xsm_ops.name, arg1); \
>>   }
>>   
>> -static inline int xsm_set_target(
>> -    xsm_default_t def, struct domain *d, struct domain *e)
>> -{
>> -    return alternative_call(xsm_ops.set_target, d, e);
>> +#define XSM_HOOK2(rtype, name, type1, type2) \
>> +static inline rtype xsm_ ## name( \
>> +    xsm_default_t def, type1 arg1, type2 arg2) \
>> +{ \
>> +    XSM_ALT_ ## rtype(xsm_ops.name, arg1, arg2); \
>>   }
>>   
>> -static inline int xsm_domctl(xsm_default_t def, struct domain *d,
>> -                             struct xen_domctl *op)
>> -{
>> -    return alternative_call(xsm_ops.domctl, d, op);
>> +#define XSM_HOOK3(rtype, name, type1, type2, type3) \
>> +static inline rtype xsm_ ## name( \
>> +    xsm_default_t def, type1 arg1, type2 arg2, type3 arg3) \
>> +{ \
>> +    XSM_ALT_ ## rtype(xsm_ops.name, arg1, arg2, arg3); \
>>   }
>>   
>> -#ifdef CONFIG_SYSCTL
>> -static inline int xsm_sysctl(xsm_default_t def, const struct xen_sysctl *op)
>> -{
>> -    return alternative_call(xsm_ops.sysctl, op);
>> +#define XSM_HOOK4(rtype, name, type1, type2, type3, type4) \
>> +static inline rtype xsm_ ## name( \
>> +    xsm_default_t def, type1 arg1, type2 arg2, type3 arg3, type4 arg4) \
>> +{ \
>> +    XSM_ALT_ ## rtype(xsm_ops.name, arg1, arg2, arg3, arg4); \
>>   }
>> -#endif
>>   
>> -static inline int xsm_evtchn_unbound(
>> -    xsm_default_t def, struct domain *d1, struct evtchn *chn, domid_t id2)
>> -{
>> -    return alternative_call(xsm_ops.evtchn_unbound, d1, chn, id2);
>> +#define XSM_HOOK5(rtype, name, type1, type2, type3, type4, type5) \
>> +static inline rtype xsm_ ## name( \
>> +    xsm_default_t def, type1 arg1, type2 arg2, type3 arg3, type4 arg4, \
>> +    type4 arg5) \
> 
> Looks like you have copy/paste typo?

Indeed. And the last two parameters of .pci_config_permission() sadly aren't
distinct enough to make the flaw apparent at build time. (That looks to be
the only hook with 5 parameters.)

Thanks much for spotting.

> I would just note there is quite a bit of churn in this patch, most of 
> it is mechanical, but makes it easy for these to slip through.

Right. Fortunately this needs doing only once.

> After fixing this typo,
> 
> Acked-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>

Thanks.

Jan



 


Rackspace

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