On 11 December 2012 18:27, Andreas Sandberg <andreas.sandberg@xxxxxxx> wrote: > On 11/12/12 15:46, Christoffer Dall wrote: >> On Tue, Dec 11, 2012 at 12:41 AM, Simon Baines >> <simonbaines2012@xxxxxxxxxxx> wrote: >>> someone can briefly explain what would be the drawback of not using the >>> architected timer support when running KVM on ARM? >>> Is it possible to run guests without that architected timer configuration >>> enabled? >> It's possible, in which case you need to use an emulated piece of >> timer hardware, which will cause you a lot more vmexits to interact >> with the timer to program it, for example. > > Is this really the case? I was under the impression that this would > require qemu (or gem5 in my case) to emulate CP15 accesses to registers > which aren't normally exposed to user space. The thing you can't do is hide the arch.timers from the guest. If the guest plays nicely and doesn't look in the relevant area of cp15 space then it can use the qemu-emulated external-to-the-cpu timer device. If the guest goes ahead and uses the arch.timers (because it's been handed a device tree that tells it to, probably) then you must have kernel support, otherwise the guest will see either UNDEF exceptions or reads of registers, depending on what bits of the timers it prods. (It is not possible for KVM to make the guest see a completely UNDEF area of cp15 space, so we can't make it look like a CPU without arch.timers in that sense.) > What makes matters more complicated is that the timer can't be > hidden from the guest since ID_PFR1 is invariant.ther. Yes. Personally the way I'd like to deal with this is just to say "arch.timers and in-kernel GIC are mandatory" (ie that not enabling them is not a supported configuration). -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
