On 07/24/2013 10:21 PM, Peter Maydell wrote: > 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 One possible solution to this issue can be the introduction of a new ioctl in KVM to report the host CPU type to the user space. Although this would change the KVM API version and raise backward compatibility issues. Moreover it seems like an overkill. Whats your take on this ? Hamayun > * 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
