On 11/12/12 18:39, Marc Zyngier wrote: > On 11/12/12 18:27, Andreas Sandberg 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. I tried to boot a recent >> Linux kernel using KVM last week and I'm pretty sure the host kernel >> sent an illegal instruction trap to the guest when it tried to enable >> the timers using the co-processor interface. What makes matters more >> complicated is that the timer can't be hidden from the guest since >> ID_PFR1 is invariant. > You probably tried to use the physical timers, which we reserve for the > host. If you use a recent enough guest, it will default to use virtual > timers, which is always available. No traps involved in this case. That seems to have been the case. I was using the officially supported kernel version for gem5 simulating a Versatile Express system, which based on an ancient version Catalin's vexpress branch. I know, we shouldn't use an ancient versions like that... However, I still find it a bit odd that unsupported features aren't masked from the ID registers. I think it would be a reasonable assumption that architected timers can be masked if they aren't emulated by the host kernel. //Andreas _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
