On 13.11.25 14:22, Jan Beulich wrote:
On 11.11.2025 18:54, Grygorii Strashko wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -311,6 +311,15 @@ struct vcpu
#endif
};
+static inline bool vcpu_is_hcall_compat(const struct vcpu *v)
Does the vcpu_ prefix really buy us much here? The per-vCPU aspect is already
conveyed by the function parameter, I'd say.
Such annotation makes it clear that operation is performed on struct vcpu
object,
which improves readability and code analyze (might help also if somebody will
ever
try split sched.h).
For example:
is_hcall_compat(curr) in the code doesn't say too much - need parse code
(or have modern editor which can parse and highlight parameter type for us,
still need some mouse manipulations:))
vcpu_is_hcall_compat(curr) - is kinda absolutely clear from the first look.
Actually - is a parameter in fact needed? It's always current afaics. (Then,
if the parameter was to stay for some reason, it would want naming "curr".)
"curr" it be
+{
+#ifdef CONFIG_COMPAT
+ return v->hcall_compat;
As long as you don't remove the struct field, ...
It is already under
#ifdef CONFIG_COMPAT
/* A hypercall is using the compat ABI? */
bool hcall_compat;
/* Physical runstate area registered via compat ABI? */
bool runstate_guest_area_compat;
#endif
which is the main reason for vcpu_is_hcall_compat() introduction.
+#else
+ return false;
+#endif /* CONFIG_COMPAT */
... why not
return IS_ENABLED(CONFIG_COMPAT) && v->hcall_compat;
--
Best regards,
-grygorii
