On 03.07.2013, at 17:41, Caraman Mihai Claudiu-B02008 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. > > Neither me though I don't find it pathetic. Please refer it to Scott. If from Linux's point of view we look like a user space program with active floating point registers, we don't have to worry about this case. Kernel code that would clobber that fp state would clobber random user space's fp state too. > >> >> I really don't see where this patch improves anything tbh. It certainly >> makes the code flow more awkward. > > I was pointing you to this: The idea of FPU/AltiVec laziness that the kernel > is struggling to achieve is to reduce the number of store/restore operations. > Without this improvement we restore the unit each time we are sched it. If an > other process take the ownership of the unit (on SMP it's even worse but don't > bother with this) the kernel store the unit state to qemu task. This can happen > multiple times during handle_exit(). > > Do you see it now? Yup. Looks good. The code flow is very hard to follow though - there are a lot of implicit assumptions that don't get documented anywhere. For example the fact that we rely on giveup_fpu() to remove MSR_FP from our thread. 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
