Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

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

 



Hey Andy,

On Wed, Jan 17, 2018 at 10:10:23AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 17, 2018 at 1:18 AM, Joerg Roedel <joro@xxxxxxxxxx> wrote:

> > Just read up on vm86 mode control transfers and the stack layout then.
> > Looks like I need to check for eflags.vm=1 and copy four more registers
> > from/to the entry stack. Thanks for pointing that out.
> 
> You could just copy those slots unconditionally.  After all, you're
> slowing down entries by an epic amount due to writing CR3 on with PCID
> off, so four words copied should be entirely lost in the noise.  OTOH,
> checking for VM86 mode is just a single bt against EFLAGS.
> 
> With the modern (rewritten a year or two ago by Brian Gerst) vm86
> code, all the slots (those actually in pt_regs) are in the same
> location regardless of whether we're in VM86 mode or not, but we're
> still fiddling with the bottom of the stack.  Since you're controlling
> the switch to the kernel thread stack, you can easily just write the
> frame to the correct location, so you should not need to context
> switch sp1 -- you can do it sanely and leave sp1 as the actual bottom
> of the kernel stack no matter what.  In fact, you could probably avoid
> context switching sp0, either, which would be a nice cleanup.

I am not sure what you mean by "not context switching sp0/sp1" ...

> So I recommend the following.  Keep sp0 as the bottom of the sysenter
> stack no matter what.  Then do:
> 
> bt $X86_EFLAGS_VM_BIT
> jc .Lfrom_vm_\@
> 
> push 5 regs to real stack, starting at four-word offset (so they're in
> the right place)
> update %esp
> ...
> .Lupdate_esp_\@
> 
> .Lfrom_vm_\@:
> push 9 regs to real stack, starting at the bottom
> jmp .Lupdate_esp_\@
> 
> Does that seem reasonable?  It's arguably much nicer than what we have
> now.

But that looks like a good idea. Having a consistent stack with and
without vm86 is certainly a nice cleanup.


Regards,

	Joerg

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux