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