On 24 July 2013 20:54, Yoder Stuart-B08248 <B08248@xxxxxxxxxxxxx> wrote: > Peter, > > Saw your comment on IRC yesterday: > > Issues: we really need to figure out what CPU we claim we're providing to the guest > > Can you elaborate on that a bit? Doesn't the guest just see the > native, host CPU type-- e.g. A15? What is the real issue with > what a guest sees? Mostly that comment is an indicator that (as far as I can tell) we have an unresolved design question that we should just nail down. I'll waffle a bit below, but I don't have a clear idea of what we should be doing. Answers of the form "every other arch is doing it this way, you should too" welcome :-) So, for ARMv7 the model is basically: * when you ask KVM to create a CPU, you ask for a specific CPU (currently an A15). The kernel knows all about the CPUs it supports. * as an implementation limitation, at the moment the kernel only supports "A15 host on A15 guest", because we don't trap or otherwise fake up for the guest any of the ID, feature or impdef system registers. So we'll refuse to create the vcpu if you ask for anything else. * QEMU has to know about the CPU too, at least in the sense that it's in its list of supported CPUs. There's no way to say "give me what the host's CPU is and I don't care what it is". * In general we trust the kernel to know what the coprocessor registers (and their reset values etc are) -- although QEMU has its own idea for the benefit of TCG, when we're using KVM it's the kernel that controls. (I have a feeling this is the opposite way round to x86.) This is a coherent design, although not all the possible bits of it are implemented just now. For ARMv8, the basic set of ioctls is the same so in some sense the approach is the same as above. However, there's a complication: * there are actually multiple host CPUs out in the field that people want to support, so an initial "only A57-on-A57" or similar isn't going to cut it * QEMU doesn't yet know about any of these CPUs, and there isn't currently public documentation for things like ID and feature register values * most v8 CPUs are probably going to be GICv3, but KVM at the moment is going to expose a GICv2 to the guest. This is the kind of "doesn't exist in real life" setup that makes me a little nervous. If we always expose the host CPU to the guest then this has a couple of issues: * we need UI for it in the target-arm bits of QEMU * we need a way to ask the kernel for "whatever you like" rather than a specific CPU * we can't ever do migration off this host CPU onto a host of a different CPU type [but maybe this isn't important...] I hope that makes sense, but as I say I'm mostly just expressing my vague sense that we haven't really nailed down how it's supposed to work yet. -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
