On Sun, Feb 02, 2014 at 08:24:08PM +0000, David Laight wrote:
> On Sun, Feb 02, 2014 at 08:41:29PM +0100, Manuel Bouyer wrote:
> > On Sun, Feb 02, 2014 at 06:53:55PM +0000, David Laight wrote:
> > > 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.
>
> Yes.
>
> > 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.
>
> Yes, probably true.
> I'd assumed that the call to fpuinit() served a purpose.
It probably does for native. For Xen things are done a bit
differently.
>
> > >
> > > 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.
>
> fork() ought to replicate the FP registers of the parent.
> I think it saves the fpu state, and then copies it.
> On bare metal it could base that descision of the state of the TS flag
> (I don't think it does). But for XEN the equivalent isn't readable.
I wouldn't expect native or Xen to be different in this case.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
