lkml.org 
[lkml]   [2015]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] x86/asm/entry/32: Replace RESTORE_RSI_RDI[_RDX] with open-coded 32-bit reads
On 06/14/2015 10:40 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko <dvlasenk@redhat.com> wrote:
>
>> +8b 74 24 68 mov 0x68(%rsp),%esi
>> +8b 7c 24 70 mov 0x70(%rsp),%edi
>> +8b 54 24 60 mov 0x60(%rsp),%edx
>
> Btw., could you (in another patch) order the restoration properly, by pt_regs
> memory order, where possible?

Will do.

> So this:
>
>> + movl RSI(%rsp), %esi
>> + movl RDI(%rsp), %edi
>> + movl RDX(%rsp), %edx
>> movl RIP(%rsp), %ecx
>> movl EFLAGS(%rsp), %r11d
>
> would become:
>
> movl RDX(%rsp), %edx
> movl RSI(%rsp), %esi
> movl RDI(%rsp), %edi
> movl RIP(%rsp), %ecx
> movl EFLAGS(%rsp), %r11d
>
> ... or so.

Actually, ecx and r11 need to be loaded first. They are not so much "restored"
as "prepared for SYSRET insn". Every cycle lost in loading these
delays SYSRET. Other loads can be reordered by CPU past SYSRET.

> In fact I'd suggest we structure movl based restoration precisely after the field
> order in the structure, and comment on cases where we depart from what's in
> pt_regs - to make it all easier to verify.

Makes sense.

I'm sending a two-patch series which (1) open-codes RESTORE_RSI_RDI
and (2) sprinkles comments in this area.



\
 
 \ /
  Last update: 2015-06-14 17:41    [W:0.220 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site