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@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.