On 25 July 2012 22:52, Michael Hope <michael.hope at linaro.org> wrote: > On 25 July 2012 20:34, Antonios Motakis > <a.motakis at virtualopensystems.com> wrote: >> Hm... So if VFPv3 is not enabled in the host, disable VFP in KVM as well? We >> would have to require at least v3 from the host, otherwise we will have to >> add extra emulation to lie to the guest about the number of registers to the >> guest. Which would be a pity. But maybe depending on VFPv3 is not too much >> to ask for... I'll go ahead and give this a shot then. > > Is this needed? The Cortex-A15 and A7 are VFPv4-D32 and, from what I > can tell, required to have the FPU. Architecturally, the Virtualization Extensions aren't dependent on either VFP or Neon. For the specific implementations we're interested in, VFP-no-Neon and no-VFP-no-Neon are both permitted configurations for the A15: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438f/CDEDAFBD.html (A7 is probably similar but I can't find the reference right now) However I would be surprised to find a core intended to run Linux and with virt support which had a no-Neon configuration. Also, as Antonios points out, you can configure a kernel without the support. I agree with Alex that in that case the best thing to do is to nuke the guest as soon as it tries anything VFP related. (Among other things, one genuine reason I've seen for disabling VFP in the kernel is so you can run on buggy early silicon with VFP errata, in which case you definitely don't want the guest messing with it either.) The potentially awkward case would be where the h/w supports 32 double registers but somebody has for some reason disabled the CONFIG_VFPv3 flag so the kernel thinks there are only 16. I'd like to make that an illegal config if we can... -- PMM
