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.
> +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
