On Tue, 22 May 2012 05:27:28 +0200, Alexander Graf <agraf at suse.de> wrote: > On 22.05.2012, at 05:00, Rusty Russell <rusty.russell at linaro.org> wrote: > > Note that in some cases, we could skip saving and restoring the host FPU > > state. But that seems like a premature optimization, > > Yup, getting things work first and fast later is usually the better > approach :). Actually, I prefer getting it to work and putting a FIXME. Then someone else can do all the tricky work ;) > How does the ARM code work here? Are you guys doing it x86 style and exit vcpu_run for every intercept or are you going the ppc way to keep inside vcpu_run until we want to return to user space? > > The former benefits a lot from not saving/restoring the host fpu state. The latter not so much :). 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. > > and makes us > > depend on the specific Linux kernel saving behavior. > > ... which should be a reasonable thing to do given that kvm is part of > the Linux kernel ;). Except the it allows changes in arch/arm/vfp/ to break code in arch/arm/kvm/. 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. Worse, we can't call kernel code to frob the FPU, since we want to stay in hyp mode to do the switch. Cheers, Rusty.
