Re: CVS commit: src/sys/arch/xen/xen

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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 <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--