On Sun, Feb 02, 2014 at 06:53:55PM +0000, David Laight wrote:
> > It's been a while since I looked at this and I don't remmeber the details,
> > but I don't think anything of fpuinit() is neeed for Xen. in netbsd-6
> > npxattach() doens't do anything either for Xen (only set i386_fpu_present to
> > 1 and init npxdna_func, which seems to be done at compile time now).
> > I think the FPU is initialised by the hypervisor. Or it's done by
> > npxdna() on the first FPU use.
> >
> > With the code as is in HEAD now, all FPU-related atf tests pass on
> > a Xen guest with 4 CPUs, so I assume it's working as expected.
>
> Something needs to set the TS (task switched) flag when a new cpu
> is added. Both amd64 and i386 'bare metal' have direct calls to
> fpuinit() to do this.
>
> If TS isn't set the first FP process that gets migrated to that cpu
> won't fault on its first FP instruction. If it has just forked it
> probably won't care, but otherwise it will all go horribly wrong.
This is the clts/stts macros/functions, isn't it ?
For Xen, this is done with the HYPERVISOR_fpu_taskswitch() hypercall.
For the boot CPU it's done in i386_proc0_tss_ldt_init().
For other CPUs it will be done when a process is created/migrated
to this CPU in i386_tls_switch(), because (l != ci->ci_fpcurlwp)
will be true.
>
> It probably doesn't matter for the boot cpu - except that you (effectively)
> clone 'random' FP registers instead of known 'initially zero' ones.
But these are zeroed on first call to the first npxdna() call,
because the lwp won't have MDL_USEDFPU set at this time.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
