On 13.11.2025 14:18, Grygorii Strashko wrote: > On 13.11.25 14:30, Jan Beulich wrote: >> On 11.11.2025 18:54, Grygorii Strashko wrote: >>> --- a/xen/arch/x86/hvm/hypercall.c >>> +++ b/xen/arch/x86/hvm/hypercall.c >>> @@ -29,10 +29,12 @@ long hvm_memory_op(unsigned long cmd, >>> XEN_GUEST_HANDLE_PARAM(void) arg) >>> return -ENOSYS; >>> } >>> >>> - if ( !vcpu_is_hcall_compat(current) ) >>> - rc = do_memory_op(cmd, arg); >>> - else >>> +#ifdef CONFIG_COMPAT >>> + if ( vcpu_is_hcall_compat(current) ) >>> rc = compat_memory_op(cmd, arg); >>> + else >>> +#endif >>> + rc = do_memory_op(cmd, arg); >> >> Why would this be needed when vcpu_is_hcall_compat() already honors >> CONFIG_COMPAT? >> (Same question then applies elsewhere, of course.) > > This I do not like by myself, but I was not able to find other options :( > > hypercall-defs.h is autogenerated and it's the only one place where functions > declarations like do_x_op() are appeared or disappeared. > So build is failing without ifdefs as compiler can't find compat_memory_op() > declaration.
Oh, I see; I hadn't thought of that aspect. I wonder if we wouldn't better take care of that in the machinery there. Cc-ing Jürgen, who did introduce this originally. Maybe he has concrete arguments against us doing so. Jan
