On 14 August 2013 07:32, Alexander Graf <agraf@xxxxxxx> wrote: > > On 13.08.2013, at 20:03, Peter Maydell wrote: > >> These patches add support to target-arm for '-cpu host'. >> The general semantics are the same as for ppc and x86 (ie "whatever >> the host kernel can support that looks basically like the host >> CPU"), but the mechanism is a little different. >> >> The kernel API (currently still proposed rather than implemented, >> hence the RFC nature of this patchset) is that the existing >> KVM_ARM_VCPU_INIT supports a new 'target' value KVM_ARM_TARGET_HOST, >> which it treats as "whatever you are". On the userspace side, >> we use this if the kernel supports it. If it doesn't then we >> know the kernel must be an A15-on-A15 only one, and so can >> safely implement '-cpu host' with KVM_ARM_TARGET_CORTEX_A15. > > How do you know what core specific registers QEMU can expect from > this particular CPU? For 99% of them we simply don't care... > Imagine ARM changes the MMU implementation in the next ARMv8 CPU. > With -cpu host you wouldn't be able to support gdbstub anymore, > because you wouldn't know whether the MMU format is the old or > the new one. ...and for the other 1% we can add a bit to the VCPU_INIT features field saying "this QEMU can handle CPUs with $weird-new-thing" and have the kernel fail CPU creation otherwise. > I really prefer the "probe the host, match it fuzzily with our > own list, pick a specific own core" way of doing -cpu host. Then > it's really only ever an alias and you don't have to worry about > all these odd special cases. I really don't want to be trying to model five hundred different CPUs inside QEMU half of which I probably won't have the documentation for. That is just going to mean "KVM+QEMU won't work on a lot of hardware when there is no reason it shouldn't". -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
