On Tue, 22 May 2012 07:43:49 +0200, Alexander Graf <agraf at suse.de> wrote: > On 22.05.2012, at 07:03, Rusty Russell <rusty.russell at linaro.org> wrote: > > The latter. So this is how it looks at the moment, assuming the guest > > always hits the FPU, we do a hyp trap and two fpu switches for each > > guest entry. > > > > Now, we could do some heuristics about FPU-intense guests, and try to > > avoid the hyp trap by always switching the FPU. We won't know the costs > > involved until we benchmark on real silicon. > > Can't you just keep the FPU in guest context until you hit vcpu_put? Check out the ppc code for 'ext' handling - it's fairly simple. Good point. The implementation I just posted saves the host FPU state on the stack, but if we put it in vcpu.arch, we could do that. Hmm, in some ways, that's simpler. I see another patch coming :) > > Except the it allows changes in arch/arm/vfp/ to break code in > > arch/arm/kvm/. > > Yeah, but that will always be the case, no? Changes in oprofile could > also hit you when you suddenly get intercepts you don't know yet. I don't know about oprofile, but currently the vfp code entirely owns the fpu. Any weird kvm hacks would be best to go in there; perhaps we could create some sane hooks though. > > And we won't spot it for ages, because it's subtle and only breaks in > > odd corner cases. This seems to be the history of floating point. > > Well - corner cases are bad of course :) > > > > > Worse, we can't call kernel code to frob the FPU, since we want to stay > > in hyp mode to do the switch. > > :( > > What's the reason we can't run all of Linux in HV mode like we do on > ppc again? ;) I'm not sure... I think most traps go to PL=1, so to get to hyp mode (PL=2) we have to bounce somewhere anyway :( Cheers, Rusty.
