* 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 me.
* 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 special
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 64-
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
>>> sl
* 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 SYSRET/IR
* 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 handl
* 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 too.
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 c
* 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
det
12 matches
Mail list logo
