The following reply was made to PR port-xen/30977; it has been noted by GNATS.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Paul Ripke <stix@stix.id.au>
Cc: Quentin Garnier <cube@cubidou.net>, gnats-bugs@NetBSD.org,
	port-xen@NetBSD.org
Subject: Re: port-xen/30977: FPU troubles
Date: Tue, 3 Jan 2006 21:21:52 +0100

 On Mon, Dec 19, 2005 at 09:34:01AM +1100, Paul Ripke wrote:
 > OK, I've had a closer look at this, and come up with the included patch,
 > which appears to work fine for me, with threaded and non-threaded 
 > programs.
 > I can't repeat the behaviour of the FPU state being not being restored,
 > restored to the wrong thread, or wiped.
 
 This is great, many thanks ! I commited the attached patch, which
 calls HYPERVISOR_fpu_taskswitch() at the end of npxsave_lwp() instead of the
 various places in which call npxsave_lwp() in the code.
 
 > 
 > Thoughts behind the patch:
 > - since clts() is a no-op under xen 2 (in xen 3, 
 > HYPERVISOR_fpu_taskswitch
 >   takes an int parameter allowing set/clear), it makes no sense to 
 > stts()
 >   inside the DNA handler. We can't clear it again.
 > - I don't get the npxsave_lwp() calls in the DNA handler. On SMP, it's
 >   used to dump an LWP's FPU state from a different CPU. On a 
 > uniprocessor,
 >   the FPU state has already been dumped by npxsave_cpu(). SMP support 
 > isn't
 >   relevant for xen 2.
 
 Sure, but as it's #ifdef MULTIPROCESSOR, there's no problem keeping
 it here. The goal is to eventually be able to share more code with i386.
 
 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --