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