Virtualization - Sep 2021 - [PATCH] x86/paravirt: use %rip-relative addressing in hook calls

While using a plain (constant) address works, its use needlessly invokes
a SIB addressing mode, making every call site one byte larger than
necessary. Instead of using an "i" constraint with address-of operator
and a 'c' operand modifier, simply use an ordinary "m"
constraint, which
the 64-bit compiler will translate to %rip-relative addressing. This way
we also tell the compiler the truth about operand usage - the memory
location gets actually read, after all.

32-bit code generation is unaffected by the change.

Signed-off-by: Jan Beulich <jbeulich at suse.com>

--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -278,7 +278,7 @@ extern void (*paravirt_iret)(void);
 
 #define paravirt_type(op)				\
 	[paravirt_typenum] "i" (PARAVIRT_PATCH(op)),	\
-	[paravirt_opptr] "i" (&(pv_ops.op))
+	[paravirt_opptr] "m" (pv_ops.op)
 #define paravirt_clobber(clobber)		\
 	[paravirt_clobber] "i" (clobber)
 
@@ -315,7 +315,7 @@ int paravirt_disable_iospace(void);
  */
 #define PARAVIRT_CALL					\
 	ANNOTATE_RETPOLINE_SAFE				\
-	"call *%c[paravirt_opptr];"
+	"call *%[paravirt_opptr];"
 
 /*
  * These macros are intended to wrap calls through one of the paravirt

On 30.09.21 14:40, Jan Beulich via Virtualization wrote:
> While using a plain (constant) address works, its use needlessly invokes
> a SIB addressing mode, making every call site one byte larger than
> necessary. Instead of using an "i" constraint with address-of
operator
> and a 'c' operand modifier, simply use an ordinary "m"
constraint, which
> the 64-bit compiler will translate to %rip-relative addressing. This way
> we also tell the compiler the truth about operand usage - the memory
> location gets actually read, after all.
> 
> 32-bit code generation is unaffected by the change.
> 
> Signed-off-by: Jan Beulich <jbeulich at suse.com>
Reviewed-by: Juergen Gross <jgross at suse.com>


Juergen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB0DE9DD628BF132F.asc
Type: application/pgp-keys
Size: 3091 bytes
Desc: OpenPGP public key
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20211005/00306067/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20211005/00306067/attachment-0001.sig>