Main Xen reported -ENOSYS if the operation is not implemented, however,
shim errorneously reported it as -EOPNOTSUPP, potentially confusing the
guest.

Make shim more consistent with Xen by reporting -ENOSYS instead.

Fixes: 49f79fe03dfe ("xen/pvshim: add grant table operations")
Fixes: 368ae9a05fee ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU")
Reported-by: Teddy Astie <teddy.astie@vates.tech>
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
---
Found while running XTF tests using pv-shim with a modified xtf-runner.

 xen/arch/x86/pv/shim.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 41000b0523..024c49c1b3 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -632,7 +632,7 @@ long pv_shim_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 
     default:
         /* No FIFO or PIRQ support for now */
-        rc = -EOPNOTSUPP;
+        rc = -ENOSYS;
         break;
     }
 
@@ -816,7 +816,7 @@ long pv_shim_grant_table_op(unsigned int cmd,
         break;
 
     default:
-        rc = -EOPNOTSUPP;
+        rc = -ENOSYS;
         break;
     }
 
-- 
2.55.0



-- 
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

On 05.10.2026 16:41, Teddy Astie wrote:
> Main Xen reported -ENOSYS if the operation is not implemented, however,
> shim errorneously reported it as -EOPNOTSUPP, potentially confusing the
> guest.

I question "erroneously". -ENOSYS has, according to my understanding, exactly
one valid use case: A top-level hypercall (normally: syscall) function which
is not implemented. Unknown sub-ops etc shouldn't be using that error
indicator, or else callers can't tell one from the other.

That said, it may still be legitimate to make the change here, as making the
change in do_grant_table_op() and do_event_channel_op() can be viewed as an
ABI change, which then we cannot easily do.

> Make shim more consistent with Xen by reporting -ENOSYS instead.
> 
> Fixes: 49f79fe03dfe ("xen/pvshim: add grant table operations")
> Fixes: 368ae9a05fee ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU")
> Reported-by: Teddy Astie <teddy.astie@vates.tech>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>

Reported-by for yourself is pretty unusual, btw.

Jan

On 10/5/26 4:11 PM, Jan Beulich wrote:
> On 05.10.2026 16:41, Teddy Astie wrote:
>> Main Xen reported -ENOSYS if the operation is not implemented, however,
>> shim errorneously reported it as -EOPNOTSUPP, potentially confusing the
>> guest.
> 
> I question "erroneously". -ENOSYS has, according to my understanding, exactly
> one valid use case: A top-level hypercall (normally: syscall) function which
> is not implemented. Unknown sub-ops etc shouldn't be using that error
> indicator, or else callers can't tell one from the other.

Maybe they shouldn't be using -ENOSYS but AFAICT the majority of hypercalls with
subops do return -ENOSYS for unknown subops (with the exception of kexec_op).
This is something we tripped over when implementing the hypercall filter for
XenServer's Secure Boot.

Ross

> 
> That said, it may still be legitimate to make the change here, as making the
> change in do_grant_table_op() and do_event_channel_op() can be viewed as an
> ABI change, which then we cannot easily do.
> 
>> Make shim more consistent with Xen by reporting -ENOSYS instead.
>>
>> Fixes: 49f79fe03dfe ("xen/pvshim: add grant table operations")
>> Fixes: 368ae9a05fee ("xen/pvshim: forward evtchn ops between L0 Xen and L2 DomU")
>> Reported-by: Teddy Astie <teddy.astie@vates.tech>
>> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
> 
> Reported-by for yourself is pretty unusual, btw.
> 
> Jan
>