On 03.07.2013, at 19:07, Scott Wood wrote: > 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@xxxxxxx] >> >> Sent: Wednesday, July 03, 2013 4:45 PM >> >> To: Caraman Mihai Claudiu-B02008 >> >> Cc: kvm-ppc@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; linuxppc- >> >> dev@xxxxxxxxxxxxxxxx >> >> 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. Oh, sure. But in that case I would strongly hope that the driver first saves off the current FPU state to the thread struct before it goes off and uses them for itself. Otherwise it would break user space, no? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
