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

[David Laight <david%l8s.co.uk@localhost>]

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 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'm about to commit code that inverts the default and assumes that the
fpu is present until fpuinit() detects it isn't.
That way it matters much less if it isn't called.
(No one runs 496SX)

        David

-- 
David Laight: david%l8s.co.uk@localhost