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

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

On Sat, Feb 01, 2014 at 10:49:44PM +0000, David Laight wrote:
> On Sat, Feb 01, 2014 at 08:07:07PM +0000, Manuel Bouyer wrote:
> > Module Name:        src
> > Committed By:       bouyer
> > Date:               Sat Feb  1 20:07:07 UTC 2014
> > 
> > Modified Files:
> >     src/sys/arch/xen/xen: hypervisor.c
> > 
> > Log Message:
> > Revert previous: calling fpuinit() leads to a panic, as a domU is not
> > allowed to manipulate cr0 directly. Xen doesn't need this, the fpu is
> > handled by the hypervisor.
> 
> I probably remember seeing that panic as well.
> 
> XEN might need the bits of fpuinit() that don't play with cr0.
> In particular a fninit and setting TS.
> Although I'm not 100% sure the TS is needed on a single cpu system.
> It isn't there on amd64, but really it does no harm.
> Without it one process will have an indererminate fp state.

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.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--