FPU state management in L4Fiasco.OC program

[Mai, Haohui]

Adam,

Thanks for your clarification.

One thing that I'm not still quite clear is that how to manage FPU context
in my settings.

The main challenge here is that to keep track the "current" pointer
(similar to the current pointer in L4Linux) -- otherwise it's difficult to
save the FPU context.

My OS only handles page faults and syscalls, and delegates scheduling
processes to L4 completely.

Handling page faults and syscalls is easy in the sense that the IPC
messages have complete information.

However, It's not immediately clear to me that how to keep track of
"current" pointer and to save / restore FPU context.

Do you have any comments on this one? I appreciate your help.

~Haohui

On Fri, Apr 13, 2012 at 4:05 AM, Adam Lackorzynski <
adam at os.inf.tu-dresden.de> wrote:

> Hi,
>
> On Thu Apr 12, 2012 at 01:34:09 -0500, Mai, Haohui wrote:
> > I forgot to mention that my OS is running simultaneously with L4Linux.
> >
> > In this case, it seems that Thread::transfer_fpu() becomes a no-op --
> > since the vcpu task for L4Linux has the FPU, but is the owner of FPU, and
> > my OS doesn't. Therefore my OS cannot grant my user-level task the FPU
> > since it doesn't have it.
> >
> > However, my OS can grant the FPU to my user-level task, once I insert an
> > floating-point instruction right before trying to grant my user-level
> > process the FPU. In this case my OS magically becomes the owner of the
> FPU,
> > and everything works smoothly.
> >
> > What I really don't understand is that how this "magic" works. First,
> both
> > L4Linux and my OS are started independently by ned:
> >
> > (1) If FPU ownership can only be transferred via exception #7 and IPC, I
> > don't understand why my OS can grab the FPU transparently, simply by
> > executing an floating-point instruction.
>
> First of all, the FPU is managed by the kernel transparently for
> threads, i.e. each thread gets its own FPU context, and this context is
> switched transparently between threads when they are scheduled.
> Now the special case is the exception handling, where it is possible to
> specify that the FPU shall be transfered back and forth. Looking at your
> example this possibility is indeed used. This makes it possible that the
> exception handler (aka kernel) can manage the FPU of other threads, i.e.
> it has to switch the context etc.
>
> > (2) If there's some transparent way that an process can get an FPU, then
> I
> > don't understand why my user-level process can't grab the FPU
> > transparently. Maybe this is because that my OS is a non-alien task but
> my
> > user-level task is an alien?
>
> Yes, exactly, this is due to the alien state of the user thread, in
> which case the exception is reflected to the handler. There, you put in
> the right FPU context and then let the thread continue with that.
>
>
>
> Adam
> --
> Adam                 adam at os.inf.tu-dresden.de
>  Lackorzynski         http://os.inf.tu-dresden.de/~adam/
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20120413/3b81ce39/attachment.htm>