On 12/8/25 14:08, Jan Beulich wrote:
On 05.12.2025 21:36, Milan Djokic wrote:
When PIRQs are not supported (e.g. for arm), XEN_DOMCTL_irq_permission
command is not handled.
This results with default (-ENOSYS) error code returned to control domain.
Update command handling to return -EOPNOTSUPP if control domain
invokes it by mistake when PIRQs are not supported.
Did you consider simply replacing the bogus ENOSYS by EOPNOTSUPP? (Assuming
the difference in error code really makes a difference to callers.)
Yes, this is the simplest approach. I didn’t do it because I wanted to
keep a distinction between commands that are part of the Xen interface
but not supported on the current configuration/platform, and commands
that don’t exist at all. I also tried to follow the existing pattern,
where unsupported commands are handled explicitly rather than falling
through to the default case (e.g. set_llc_colors, soft_reset, etc).
If this distinction isn’t useful, then yes, I can definitely just rely
on a default-case error.
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -555,14 +555,14 @@ static XSM_INLINE int cf_check xsm_unmap_domain_irq(
XSM_ASSERT_ACTION(XSM_HOOK);
return xsm_default_action(action, current->domain, d);
}
-
+#ifdef CONFIG_HAS_PIRQ
static XSM_INLINE int cf_check xsm_irq_permission(
XSM_DEFAULT_ARG struct domain *d, int pirq, uint8_t allow)
{
XSM_ASSERT_ACTION(XSM_HOOK);
return xsm_default_action(action, current->domain, d);
}
-
+#endif
static XSM_INLINE int cf_check xsm_iomem_permission(
XSM_DEFAULT_ARG struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
{
Why would you zap blank lines like this (also elsewhere)?
Will fix this.
