On 10.09.2013, at 05:22, Paul Mackerras wrote: > Now that we have the vcpu floating-point and vector state stored in > the same type of struct as the main kernel uses, we can load that > state directly from the vcpu struct instead of having extra copies > to/from the thread_struct. Similarly, when the guest state needs to > be saved, we can have it saved it directly to the vcpu struct by > setting the current->thread.fp_save_area and current->thread.vr_save_area > pointers. That also means that we don't need to back up and restore > userspace's FP/vector state. This all makes the code simpler and > faster. > > Note that it's not necessary to save or modify current->thread.fpexc_mode, > since nothing in KVM uses or is affected by its value. Nor is it > necessary to touch used_vr or used_vsr. > > Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx> > --- > arch/powerpc/kvm/book3s_pr.c | 72 ++++++++++---------------------------------- > arch/powerpc/kvm/booke.c | 16 ---------- > arch/powerpc/kvm/booke.h | 4 ++- > 3 files changed, 19 insertions(+), 73 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c > index 90be91c..5eae919 100644 > --- a/arch/powerpc/kvm/book3s_pr.c > +++ b/arch/powerpc/kvm/book3s_pr.c > @@ -462,16 +462,16 @@ void kvmppc_giveup_ext(struct kvm_vcpu *vcpu, ulong msr) > * both the traditional FP registers and the added VSX > * registers into thread.fp_state.fpr[]. > */ > - if (current->thread.regs->msr & MSR_FP) > + if (t->regs->msr & MSR_FP) > giveup_fpu(current); If you make a second version of this call that also gets a state area as parameter, you don't need the pointer in the thread struct anymore, no? Or do you? Ah, you want to be able to grab the FPU for in-kernel FPU using code, so it needs to be seamless. Fiar enough - pointer it is then :). 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
