> -----Original Message----- > From: Peter Maydell [mailto:peter.maydell@xxxxxxxxxx] > Sent: Wednesday, July 24, 2013 3:22 PM > To: Yoder Stuart-B08248 > Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: CPU seen by guest in VM > > 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. On the question of what GIC is exposed, wouldn't that be exposed in the device tree and be orthogonal to the question of which CPU a VM sees? Even if ARM v8 CPU requires a GICv3, it seems like a bad assumption for an OS to just assume a GIC v3 without checking what is advertised in the device tree. Stuart _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
