On Mon, Jan 22, 2018 at 2:11 AM, Joerg Roedel <joro@xxxxxxxxxx> 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. -- 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>
