Juergen Gross
2021-Oct-05 07:43 UTC
[PATCH] x86/paravirt: use %rip-relative addressing in hook calls
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>
Jan Beulich
2021-Nov-23 09:29 UTC
[PATCH] x86/paravirt: use %rip-relative addressing in hook calls
On 05.10.2021 09:43, Juergen Gross wrote:> 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>Thanks. I notice this wasn't part of your 5.16-rc1 pull request, nor did it make it into Linus'es tree via any other route. May I ask what the plans here are? Jan