On Tue, Jul 24, 2012 at 6:12 AM, Rusty Russell <rusty.russell at linaro.org>wrote: > On Mon, 23 Jul 2012 20:21:28 +0100, 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. > > Agreed. > Actually, I'm probably interested in userspace access as well, so we should follow up on that :) > > > > + /* 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)? > > OK, I think we should reuse vfp_hard_struct (and ignore the 'cpu' field). > > I'd use vfp_save_state/vfp_restore_state in a separate follow-up patch, > since we'd have to write vfp_restore_state, and should add a comment > noting that they can now be called from hyp mode. > > If everyone agrees on reusing vfp_hard_struct, I'm ok with changing it. But vfp_save_state and friends could be a problem as far as I understand. I'd suggest we just reuse the macros in arch/arm/include/asm/vfpmacros.h, that should reduce code duplication quite a lot without shoehorning vfp_save_state in context switch code. The macros refer to out of date instruction mnemonics, but they should be just perfect now that we don't try to save state on the stack anymore. -Antonios -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/kvmarm/attachments/20120724/c8359fd1/attachment.html
