* Andy Lutomirski wrote:
> On Thu, Jun 18, 2015 at 3:11 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> > The only low level bits remaining in assembly will be low level hardware
> >> > ABI
> >> > details: saving registers and restoring registers to the expected format
> >>
On Thu, Jun 18, 2015 at 3:11 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> > The only low level bits remaining in assembly will be low level hardware
>> > ABI
>> > details: saving registers and restoring registers to the expected format -
>> > no
>> > 'active' code whatsoever.
>>
>>
* Andy Lutomirski wrote:
> > So assuming you fix the UML build I'm inclined to go for it, even in this
> > incomplete form, to increase testing coverage.
> >
> > Doing that will also decrease ongoing merge friction between your work and
> > other entry code cleanups ...
>
> Sounds good to
* Andy Lutomirski wrote:
> > The only low level bits remaining in assembly will be low level hardware
> > ABI
> > details: saving registers and restoring registers to the expected format -
> > no
> > 'active' code whatsoever.
>
> I think this is true for syscalls. Getting the weird
On Thu, Jun 18, 2015 at 3:11 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@amacapital.net wrote:
The only low level bits remaining in assembly will be low level hardware
ABI
details: saving registers and restoring registers to the expected format -
no
'active' code
* Andy Lutomirski l...@amacapital.net wrote:
On Thu, Jun 18, 2015 at 3:11 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@amacapital.net wrote:
The only low level bits remaining in assembly will be low level hardware
ABI
details: saving registers and restoring
* Andy Lutomirski l...@amacapital.net wrote:
The only low level bits remaining in assembly will be low level hardware
ABI
details: saving registers and restoring registers to the expected format -
no
'active' code whatsoever.
I think this is true for syscalls. Getting the weird
* Andy Lutomirski l...@amacapital.net wrote:
So assuming you fix the UML build I'm inclined to go for it, even in this
incomplete form, to increase testing coverage.
Doing that will also decrease ongoing merge friction between your work and
other entry code cleanups ...
Sounds
On Jun 17, 2015 2:49 AM, "Ingo Molnar" wrote:
>
>
> * Andy Lutomirski wrote:
>
>
> > I tried to clean it up incrementally, but I decided it was too hard.
> > Instead,
> > this series just replaces the code. It seems to work.
>
> Any known bugs beyond UML build breakage?
One minor one: the
On Wed, Jun 17, 2015 at 3:32 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> The main things that are missing are that I haven't done the 32-bit parts
>> (anyone want to help?) and therefore I haven't deleted the old C code. I
>> also
>> think this may break UML for trivial reasons.
>
On Wed, Jun 17, 2015 at 3:13 AM, Richard Weinberger
wrote:
> On Wed, Jun 17, 2015 at 11:48 AM, Ingo Molnar wrote:
>>
>> * Andy Lutomirski wrote:
>>
>>> This is incomplete, but it's finally good enough that I think it's
>>> time to get other opinions on it. It is a complete rewrite of the
>>>
* Ingo Molnar wrote:
> Basically there would be a single C function we'd call, which returns a
> condition (or fixes up its return address on the stack directly) to determine
> between the SYSRET and IRET return paths.
This we could do by returning the syscall result in RAX, and the
* Richard Weinberger wrote:
> On Wed, Jun 17, 2015 at 11:48 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> This is incomplete, but it's finally good enough that I think it's
> >> time to get other opinions on it. It is a complete rewrite of the
> >> slow path code that
* Andy Lutomirski wrote:
> The main things that are missing are that I haven't done the 32-bit parts
> (anyone want to help?) and therefore I haven't deleted the old C code. I
> also
> think this may break UML for trivial reasons.
So I'd suggest moving most of the SYSRET fast path to C
On Wed, Jun 17, 2015 at 11:48 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> This is incomplete, but it's finally good enough that I think it's
>> time to get other opinions on it. It is a complete rewrite of the
>> slow path code that handles exits to user mode.
>
> Modulo the small
* Andy Lutomirski wrote:
> This is incomplete, but it's finally good enough that I think it's
> time to get other opinions on it. It is a complete rewrite of the
> slow path code that handles exits to user mode.
Modulo the small comments I made about the debug checks interface plus naming
* Ingo Molnar mi...@kernel.org wrote:
Basically there would be a single C function we'd call, which returns a
condition (or fixes up its return address on the stack directly) to determine
between the SYSRET and IRET return paths.
This we could do by returning the syscall result in RAX, and
On Wed, Jun 17, 2015 at 11:48 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
This is incomplete, but it's finally good enough that I think it's
time to get other opinions on it. It is a complete rewrite of the
slow path code that handles exits to user mode.
* Andy Lutomirski l...@kernel.org wrote:
This is incomplete, but it's finally good enough that I think it's
time to get other opinions on it. It is a complete rewrite of the
slow path code that handles exits to user mode.
Modulo the small comments I made about the debug checks interface
* Andy Lutomirski l...@kernel.org wrote:
The main things that are missing are that I haven't done the 32-bit parts
(anyone want to help?) and therefore I haven't deleted the old C code. I
also
think this may break UML for trivial reasons.
So I'd suggest moving most of the SYSRET fast
* Richard Weinberger richard.weinber...@gmail.com wrote:
On Wed, Jun 17, 2015 at 11:48 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
This is incomplete, but it's finally good enough that I think it's
time to get other opinions on it. It is a
On Wed, Jun 17, 2015 at 3:32 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
The main things that are missing are that I haven't done the 32-bit parts
(anyone want to help?) and therefore I haven't deleted the old C code. I
also
think this may break UML
On Wed, Jun 17, 2015 at 3:13 AM, Richard Weinberger
richard.weinber...@gmail.com wrote:
On Wed, Jun 17, 2015 at 11:48 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
This is incomplete, but it's finally good enough that I think it's
time to get other opinions
On Jun 17, 2015 2:49 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
I tried to clean it up incrementally, but I decided it was too hard.
Instead,
this series just replaces the code. It seems to work.
Any known bugs beyond UML build breakage?
One
This is incomplete, but it's finally good enough that I think it's
time to get other opinions on it. It is a complete rewrite of the
slow path code that handles exits to user mode.
The exit-to-usermode code is copied in several places and is written
in a nasty combination of asm and C. It's not
This is incomplete, but it's finally good enough that I think it's
time to get other opinions on it. It is a complete rewrite of the
slow path code that handles exits to user mode.
The exit-to-usermode code is copied in several places and is written
in a nasty combination of asm and C. It's not
26 matches
Mail list logo
