On Tue, Jul 24, 2012 at 12:20 PM, Antonios Motakis < a.motakis at virtualopensystems.com> wrote: > > > 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 > Hello all, So I had another look into vfp_hard_struct. The struct seems to be different depending on what version of VFP we have compiled the kernel to support (if at all), in particular the number of registers. I have designed the current so it doesn't rely on the host's VFP support; in theory you would be able to run VFP guests without including any support in the host (similarly to how on PC you can run 64bit guests on 32bit hosts). If we change the implementation to match what is being supported by the host, then not only we loose this (admittetly not very common, but still pretty neat) use case, but we will also have to maintain emulating the hardwares registers which report the VFP version, and number of registers, etc to the guest. So we would actually have *more* code to update between VFP revisions. I'd consider keeping the current implementation for this, where we just pass what the hardware can do to the guest, without relying on what the host has been build to do with vfp. What do you guys think? -Antonios -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/kvmarm/attachments/20120724/13c8437a/attachment.html
