On Sun, Aug 25, 2013 at 04:11:51PM +0100, Peter Maydell wrote: > On 25 August 2013 15:42, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > > Are ARM cpu features not enumerable and the only way to know what is > > supported by a core is by its id? I do see feature registers in the > > spec, so why wouldn't we want to be able to disable/enable features > > individually? > > It's complicated. There are feature registers which have various > bits, but only some combinations are architecturally valid. In any > case a guest might reasonably legitimately assume "this is an A15 > so it will have architected timers", for example, and not bother > testing feature bits. That's sad. If feature bit is available I would expect well behaved guest to test it. BTW is there architectural way to tell OS that it runs as a guest? There is dedicated CPUID bit on x86 for that which is obviously never set on real CPUs. > Some feature bits really do have to match the > real hardware, like ones that say "you need to explicitly flush the > branch predictor". A lot are feature bits that are simply mandatory > for any ARMv7 or later processor (which is what you need for KVM > to work at all). What if you want to emulate older arm arch for a guest? > And buried in there might possibly be a few features > that it might actually make sense to enable/disable separately (like > "do we have Neon?"). > > So what we have for now is that the INIT_VCPU ioctl has space > for feature flags (currently unused in v7; in v8 there's a "make the > VM be a 32 bit VM on a 64 bit CPU" flag), so we could wire those > up some day. (We don't have any support in QEMU for saying > "I want an ARM CPU with features X and Y but not Z" yet either.) > Do we have a way to ask KVM if it can support those features? -- Gleb. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
