This patch series provides minor updates to the domctl and sysctl handling
of unsupported commands. Currently the behavior diverges: some commands
return -EOPNOTSUPP, while others fall back to the generic -ENOSYS.  
This series aligns the behavior so that unsupported commands consistently
return the appropriate error code, allowing the control domain to correctly
identify unsupported operations.

Where possible, IS_ENABLED() is used to detect disabled commands at compile
time, enabling dead code elimination.  For commands where stubs are
provided, the stub functions are updated to return the correct error code.

The only exception is XEN_DOMCTL_irq_permission, which cannot use
IS_ENABLED() due to PIRQ-specific structures being unavailable when PIRQ
support is off.  In this case, classic #ifdef blocks remain in
place.

There may be future updates in this regard. This initial series is intended to 
get maintainers' feedback on the approach taken.

Milan Djokic (4):
  arm/domain: Update SBSA_VUART_CONSOLE config option handling
  domctl: Provide appropriate error code when PIRQs are not supported
  domctl: Provide appropriate error code when VM events are not
    supported
  sysctl: align handling of unsupported commands

 xen/arch/arm/dom0less-build.c     |  4 ++++
 xen/arch/arm/domctl.c             |  3 +++
 xen/arch/arm/include/asm/vpl011.h |  2 +-
 xen/common/domctl.c               | 25 ++++++++++++++---------
 xen/common/sysctl.c               | 34 ++++++++++++++++++-------------
 xen/include/xen/livepatch.h       |  2 +-
 xen/include/xen/perfc.h           |  4 +++-
 xen/include/xen/spinlock.h        |  6 +++---
 xen/include/xen/trace.h           |  2 +-
 xen/include/xsm/dummy.h           |  4 ++--
 xen/include/xsm/xsm.h             |  6 ++++--
 xen/xsm/dummy.c                   |  2 ++
 xen/xsm/flask/hooks.c             |  5 ++++-
 13 files changed, 63 insertions(+), 36 deletions(-)

-- 
2.43.0

On 05.12.2025 21:36, Milan Djokic wrote:
> This patch series provides minor updates to the domctl and sysctl handling
> of unsupported commands. Currently the behavior diverges: some commands
> return -EOPNOTSUPP, while others fall back to the generic -ENOSYS.  
> This series aligns the behavior so that unsupported commands consistently
> return the appropriate error code, allowing the control domain to correctly
> identify unsupported operations.

What, even after having looked at all the patches (and their descriptions),
still isn't clear to me is why the distinction ENOSYS vs EOPNOTSUPP would
matter. Tool stacks still need to be prepared to get back ENOSYS, at the
very least as long as they mean to run on older hypervisors as well. And
with Penny's work to allow excluding domctl/sysctl altogether, I expect
ENOSYS would then also be what results if that option is made use of.

Jan

Hello Jan,

On 12/8/25 14:35, Jan Beulich wrote:
> On 05.12.2025 21:36, Milan Djokic wrote:
>> This patch series provides minor updates to the domctl and sysctl handling
>> of unsupported commands. Currently the behavior diverges: some commands
>> return -EOPNOTSUPP, while others fall back to the generic -ENOSYS.
>> This series aligns the behavior so that unsupported commands consistently
>> return the appropriate error code, allowing the control domain to correctly
>> identify unsupported operations.
> 
> What, even after having looked at all the patches (and their descriptions),
> still isn't clear to me is why the distinction ENOSYS vs EOPNOTSUPP would
> matter. Tool stacks still need to be prepared to get back ENOSYS, at the
> very least as long as they mean to run on older hypervisors as well. And
> with Penny's work to allow excluding domctl/sysctl altogether, I expect
> ENOSYS would then also be what results if that option is made use of.
> 

I think that ENOSYS and EOPNOTSUPP are both handled properly by the 
toolstack. This change is more related to control domains without 
standard tool stack (e.g. zephyr or xtf domain). Especially for xtf 
tests, we expect that consistent error code is provided for unsupported 
hypercall commands. Right now this is not the case.
Still, this is not a ‘must’, but in my view it would be better if we had 
the handling aligned between different hypercalls and commands.

BR,
Milan