FPU state management in L4Fiasco.OC program

Adam Lackorzynski adam at os.inf.tu-dresden.de
Fri Apr 13 11:05:00 CEST 2012


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/




More information about the l4-hackers mailing list