On Mon, Nov 27, 2017 at 10:14:24AM +0100, Peter Zijlstra wrote:
> But if we can freely spill here, should we not do the kernel switch
> instead of doing this user mapping? The way I understand things, the
> less of these magic mappings we have the better.
Turns out, we don't need more scratch reg
On Fri, Nov 24, 2017 at 08:17:06AM -0800, Andy Lutomirski wrote:
> On Fri, Nov 24, 2017 at 5:47 AM, Peter Zijlstra wrote:
> > On Fri, Nov 24, 2017 at 10:14:35AM +0100, Ingo Molnar wrote:
> >> From: Dave Hansen
> >>
> >> There is some rather arcane code to help when an IRET returns
> >> to 16-bit
From: Dave Hansen
There is some rather arcane code to help when an IRET returns
to 16-bit segments. It is referred to as the "espfix" code.
This consists of a few per-cpu variables:
espfix_stack: tells us where the stack is allocated
(the bottom)
espfix_wad
On Fri, Nov 24, 2017 at 5:47 AM, Peter Zijlstra wrote:
> On Fri, Nov 24, 2017 at 10:14:35AM +0100, Ingo Molnar wrote:
>> From: Dave Hansen
>>
>> There is some rather arcane code to help when an IRET returns
>> to 16-bit segments. It is referred to as the "espfix" code.
>> This consists of a few
On Fri, Nov 24, 2017 at 10:14:35AM +0100, Ingo Molnar wrote:
> From: Dave Hansen
>
> There is some rather arcane code to help when an IRET returns
> to 16-bit segments. It is referred to as the "espfix" code.
> This consists of a few per-cpu variables:
>
> espfix_stack: tells us where the
From: Dave Hansen
There is some rather arcane code to help when an IRET returns
to 16-bit segments. It is referred to as the "espfix" code.
This consists of a few per-cpu variables:
espfix_stack: tells us where the stack is allocated
(the bottom)
espfix_wad
6 matches
Mail list logo