On Mon, Jul 23, 2012 at 9:21 PM, Peter Maydell <peter.maydell at linaro.org>wrote:
> On 23 July 2012 19:41, Antonios Motakis
> <a.motakis at virtualopensystems.com> wrote:
> > This patch applies to the v9 patch series of KVM,
> > i.e. commit d5321dceeaccf756755e76b38d8b5905bd99d250
> >
> > In this patch, we use the Hyp Coprocessor Trap Register
> > (HPCTR) to trap VFP/NEON instructions, and switch the FPU
> > state at that point. After a guest exit, the VFP state is
> > returned to the host.
>
> We need to also expose the guest VFP state to userspace
> for save/restore, but since I think that should be done
> via the same ioctls Rusty has proposed for cp15 save/load
> we should do that in a later patch I think.
>
I agree, and I agree.
>
> > +enum cp10_regs {
> > + FPEXC, /* Floating Point Exception Control
> Register */
> > + FPSCR, /* Floating Point Status and Control
> Register */
> > + FPINST, /* Common VFP Subarchitecture Registers
> */
> > + FPINST2,
> > + nr_cp10_regs
> > +};
> > +
> > struct kvm_vcpu_arch {
> > struct kvm_vcpu_regs regs;
> >
> > /* System control coprocessor (cp15) */
> > u32 cp15[nr_cp15_regs];
> >
> > + /* Floating point registers (VFP and Advanced SIMD/NEON) */
> > + u32 guest_cp10[nr_cp10_regs];
> > + u32 guest_cp11[64];
> > +
> > + /* Saved host vfp state. */
> > + u32 host_cp10[nr_cp10_regs];
> > + u32 host_cp11[64];
>
> I notice that this is saving basically the same info as vfp_hard_struct
> in arch/arm/include/asm/fpstate.h, but with more opaque structure field
> names. Does it make sense to reuse that struct (and perhaps even
> the vfp_save_state/vfp_restore_state functions)?
>
> -- PMM
>
Hm, yes we can reuse vfp_hard_struct, as long as people don't mind the
extra cpu variable. We better leave vfp_save_state functions out, because
then we'd have to map them to the hypermode memory space, using some neat
macros is simpler for the context switch code. (Also I don't know if
calling a function is acceptable in the first place from the context switch
code)
Thanks a lot for your comments!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/kvmarm/attachments/20120724/3c801bf1/attachment-0001.html
