[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 04/12] xen/x86: modify hvm_memory_op() prototype
On 18.10.21 14:31, Jan Beulich wrote: On 15.10.2021 14:51, Juergen Gross wrote:hvm_memory_op() should take an unsigned long as cmd, like do_memory_op(). As hvm_memory_op() is basically just calling do_memory_op() (or compat_memory_op()) passing through the parameters the cmd parameter should have no smaller size than that of the called functions. Signed-off-by: Juergen Gross <jgross@xxxxxxxx>Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Nevertheless ...--- a/xen/arch/x86/hvm/hypercall.c +++ b/xen/arch/x86/hvm/hypercall.c @@ -31,7 +31,7 @@ #include <public/hvm/hvm_op.h> #include <public/hvm/params.h>-static long hvm_memory_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)+static long hvm_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) { long rc;... I think this would even better be dealt with by splitting the function into a native one (using unsigned long) and a compat one (using unsigned int). Why? In 32-bit case the value is naturally limited to 32 bits width zero-extending perfectly fine to unsigned long. Otherwise I couldn't use the same definition later. Juergen Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |