On 09.12.2025 13:48, Milan Djokic wrote: > 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.
Before you (possibly) follow this route, maybe I should mention that there have been discussions around this in the past (sorry, no pointers, too long ago). IOW ahead of any consolidation (and making things consistent), imo as a community we need to settle on where exactly we consider ENOSYS valid to be used. My take is that almost all of the uses we (still) have are wrong. In particular all the ones for "unknown sub-op". Jan
