Re: [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laziness

[Scott Wood <scottwood@freescale.com>]

On 07/03/2013 10:11:50 AM, Alexander Graf wrote:
> 
> On 03.07.2013, at 15:55, Caraman Mihai Claudiu-B02008 wrote:
> 
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Wednesday, July 03, 2013 4:45 PM
> >> To: Caraman Mihai Claudiu-B02008
> >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org
> >> Subject: Re: [PATCH 3/6] KVM: PPC: Book3E: Increase FPU laziness
> >>
> >>
> >> On 03.07.2013, at 14:42, Mihai Caraman wrote:
> >>
> >>> Increase FPU laziness by calling kvmppc_load_guest_fp() just  
> before
> >>> returning to guest instead of each sched in. Without this  
> improvement
> >>> an interrupt may also claim floting point corrupting guest state.
> >>
> >> Not sure I follow. Could you please describe exactly what's  
> happening?
> >
> > This was already discussed on the list, I will forward you the  
> thread.
> 
> The only thing I've seen in that thread was some pathetic theoretical  
> case where an interrupt handler would enable fp and clobber state  
> carelessly. That's not something I'm worried about.

On x86 floating point registers can be used for memcpy(), which can be  
used in interrupt handlers.  Just because it doesn't happen on PPC  
today doesn't make it a "pathetic theoretical case" that we should  
ignore and leave a landmine buried in the KVM code.  Even power7 is  
using something similar for copyuser (which isn't called from interrupt  
context, but it's not a huge leap from that to doing it in memcpy).

It also doesn't seem *that* farfetched that some driver for unusual  
hardware could decide it needs FP in its interrupt handler, and call  
the function that is specifically meant to ensure that.  It's frowned  
upon, but that doesn't mean nobody will ever do it.

-Scott