[lkml]   [2018]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack
On Mon, Jan 22, 2018 at 2:11 AM, Joerg Roedel <> wrote:
> Hey Andy,
> On Fri, Jan 19, 2018 at 08:30:33AM -0800, Andy Lutomirski wrote:
>> I meant that we could have sp0 have a genuinely constant value per
>> cpu. That means that the entry trampoline ends up with RIP, etc in a
>> different place depending on whether VM was in use, but the entry
>> trampoline code should be able to handle that. sp1 would have a value
>> that varies by task, but it could just point to the top of the stack
>> instead of being changed depending on whether VM is in use. Instead,
>> the entry trampoline would offset the registers as needed to keep
>> pt_regs in the right place.
>> I think you already figured all of that out, though :)
> Yes, and after looking a while into it, it would make a nice cleanup for
> the entry code. On the other side, it would change the layout for the
> in-kernel 'struct pt_regs', so that the user-visible pt_regs ends up
> with a different layout than the one we use in the the kernel.

I don't think this is necessarily the case. We end up with four more
fields that are logically there at the end of pt_regs (which is
already kind-of-sort-of the case), but we don't actually need to put
them in struct pt_regs. We just end up with (regs + 1) != "top of
task stack", but even that has precedent -- it's already true for
tasks in vm86 mode.

> This can certainly be all worked out, but it makes this nice entry-code
> cleanup not so nice and clean anymore. At least the work required to
> make it work without breaking user-space is not in the scope of this
> patch-set.

Agreed. This should probably be saved for later. Except that your
patch set still needs to come up with some way to function correctly
on vm86.

 \ /
  Last update: 2018-01-22 18:48    [W:0.092 / U:0.912 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site