On 11/12/12 18:40, Peter Maydell wrote: > On 11 December 2012 18:34, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >> On 11 December 2012 18:27, Andreas Sandberg <andreas.sandberg@xxxxxxx> wrote: >>> What makes matters more complicated is that the timer can't be >>> hidden from the guest since ID_PFR1 is invariant.ther. >> Yes. > Forgot to say, KVM should support trapping to hyp on the ID registers > (via HCR.TID[0123]) and returning values suitable for the virtual > CPU we're exposing to the guest. We don't do that at the moment but > will need to (for instance for A15 guest on A7 host, a combo we > can't pull off at the moment). That'd be very useful for the type of work I'm doing. We're using KVM as an accelerator for the gem5 system simulator, which means that we want to switch between virtualized CPUs and the gem5 CPU models. We usually get away with this as long as the guest kernel is configured without the features that gem5 doesn't support, but it would be very useful to be able to mask out features like Thumb or Jazelle. I can definitely see why you don't want to implement this for the initial version, getting it right seems fairly complex. I'm looking forward to when it happens! > Speaking of cans of worms and the arch.timers, an interesting > question we thought of the other week is "how does VM migration > work between host machines whose arch.timers run at different > frequencies?" Judging from a quick glance at the spec., I'd say that it looks like this can't be done properly without a collaborative guest. In general, it seems like migration across different CPU types will be "interesting". //Andreas _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
