fx_init schedule in atomic

fx_init schedule in atomic

[Andrea Arcangeli]

Hello,

This make sure not to schedule in atomic during fx_init. I also
changed the name of fpu_init to fx_finit to avoid duplicating the name
with fpu_init that is already used in the kernel, this makes grep
simpler if nothing else.

Signed-off-by: Andrea Arcangeli <andrea@qumranet.com>

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 578a0c1..5398b1c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3701,10 +3702,19 @@ void fx_init(struct kvm_vcpu *vcpu)
 {
 	unsigned after_mxcsr_mask;
 
+	/*
+	 * Touch the fpu the first time in non atomic context as if
+	 * this is the first fpu instruction the exception handler
+	 * will fire before the instruction returns and it'll have to
+	 * allocate ram with GFP_KERNEL.
+	 */
+	if (!used_math())
+		fx_save(&vcpu->arch.host_fx_image);
+
 	/* Initialize guest FPU by resetting ours and saving into guest's */
 	preempt_disable();
 	fx_save(&vcpu->arch.host_fx_image);
-	fpu_init();
+	fx_finit();
 	fx_save(&vcpu->arch.guest_fx_image);
 	fx_restore(&vcpu->arch.host_fx_image);
 	preempt_enable();
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 4baa9c9..b9a1421 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -627,7 +635,7 @@ static inline void fx_restore(struct i387_fxsave_struct *image)
 	asm("fxrstor (%0)":: "r" (image));
 }
 
-static inline void fpu_init(void)
+static inline void fx_finit(void)
 {
 	asm("finit");
 }

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: fx_init schedule in atomic

[Avi Kivity]

Andrea Arcangeli wrote:
> This make sure not to schedule in atomic during fx_init. I also
> changed the name of fpu_init to fx_finit to avoid duplicating the name
> with fpu_init that is already used in the kernel, this makes grep
> simpler if nothing else.
>
>   

Applied, thanks. Dynamic allocation for the fpu state was introduced in 
2.6.26-rc, right?

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: fx_init schedule in atomic

[Andrea Arcangeli]

On Fri, May 02, 2008 at 12:28:32PM +0300, Avi Kivity wrote:
> Applied, thanks. Dynamic allocation for the fpu state was introduced in 
> 2.6.26-rc, right?

It seems very recent, hit mainline on 30 Apr.

Also we may want to think if there's something cheaper than fx_save to
trigger a math exception that doesn't alter the fpu state, I didn't
think much about it given it's such a slow path that's probably not
worth changing with something more complicated anyway. And bringing in
a few l1 exclusive cachelines in the cpu should allow the second
instruction to repeat faster than the first.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: fx_init schedule in atomic

[Avi Kivity]

Andrea Arcangeli wrote:
> On Fri, May 02, 2008 at 12:28:32PM +0300, Avi Kivity wrote:
>   
>> Applied, thanks. Dynamic allocation for the fpu state was introduced in 
>> 2.6.26-rc, right?
>>     
>
> It seems very recent, hit mainline on 30 Apr.
>
> Also we may want to think if there's something cheaper than fx_save to
> trigger a math exception that doesn't alter the fpu state, I didn't
> think much about it given it's such a slow path that's probably not
> worth changing with something more complicated anyway. And bringing in
> a few l1 exclusive cachelines in the cpu should allow the second
> instruction to repeat faster than the first.
>   

Oh, it's hardly performance critical.  I think it is fine as is.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone