[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 07/13] x86/paravirt: Simplify ____PVOP_CALL()



On Wed, Oct 04, 2017 at 10:58:28AM -0500, Josh Poimboeuf wrote:
> Remove the inline asm duplication in ____PVOP_CALL().
> 
> Also add 'IS_ENABLED(CONFIG_X86_32)' to the return variable logic,
> making the code clearer and rendering the comment unnecessary.
> 
> Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> ---
>  arch/x86/include/asm/paravirt_types.h | 36 
> +++++++++++++----------------------
>  1 file changed, 13 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/x86/include/asm/paravirt_types.h 
> b/arch/x86/include/asm/paravirt_types.h
> index ab7aabe6b668..01f9e10983c1 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -529,29 +529,19 @@ int paravirt_disable_iospace(void);
>               rettype __ret;                                          \
>               PVOP_CALL_ARGS;                                         \
>               PVOP_TEST_NULL(op);                                     \

Newline here...

> -             /* This is 32-bit specific, but is okay in 64-bit */    \
> -             /* since this condition will never hold */              \
> -             if (sizeof(rettype) > sizeof(unsigned long)) {          \
> -                     asm volatile(pre                                \
> -                                  paravirt_alt(PARAVIRT_CALL)        \
> -                                  post                               \
> -                                  : call_clbr, ASM_CALL_CONSTRAINT   \
> -                                  : paravirt_type(op),               \
> -                                    paravirt_clobber(clbr),          \
> -                                    ##__VA_ARGS__                    \
> -                                  : "memory", "cc" extra_clbr);      \
> -                     __ret = (rettype)((((u64)__edx) << 32) | __eax); \
> -             } else {                                                \
> -                     asm volatile(pre                                \
> -                                  paravirt_alt(PARAVIRT_CALL)        \
> -                                  post                               \
> -                                  : call_clbr, ASM_CALL_CONSTRAINT   \
> -                                  : paravirt_type(op),               \
> -                                    paravirt_clobber(clbr),          \
> -                                    ##__VA_ARGS__                    \
> -                                  : "memory", "cc" extra_clbr);      \
> -                     __ret = (rettype)(__eax & PVOP_RETMASK(rettype));       
> \
> -             }                                                       \
> +             asm volatile(pre                                        \
> +                          paravirt_alt(PARAVIRT_CALL)                \
> +                          post                                       \
> +                          : call_clbr, ASM_CALL_CONSTRAINT           \
> +                          : paravirt_type(op),                       \
> +                            paravirt_clobber(clbr),                  \
> +                            ##__VA_ARGS__                            \
> +                          : "memory", "cc" extra_clbr);              \

... and here goes a long way towards readability. :)

> +             if (IS_ENABLED(CONFIG_X86_32) &&                        \
> +                 sizeof(rettype) > sizeof(unsigned long))            \
> +                     __ret = (rettype)((((u64)__edx) << 32) | __eax);\
> +             else                                                    \
> +                     __ret = (rettype)(__eax & PVOP_RETMASK(rettype));\
>               __ret;                                                  \
>       })

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.