On Wed, Aug 14, 2013 at 07:31:59PM +0200, Alexander Graf wrote: > > On 14.08.2013, at 19:26, Christoffer Dall wrote: > > > On Wed, Aug 14, 2013 at 11:30:46AM +0200, Alexander Graf wrote: > >> > >> On 14.08.2013, at 11:23, Peter Maydell wrote: > >> > >>> On 14 August 2013 10:11, Alexander Graf <agraf@xxxxxxx> wrote: > >>>> You're right, the main difference is that KVM doesn't have any > >>>> idea what a "host" style CPU is. It only knows how to report to QEMU > >>>> what the current host CPU would be, so that anything from VCPU_INIT > >>>> onwards is 100% identical regardless of whether the user said > >>>> -cpu host or -cpu xxx. > >>>> > >>>> I'm still puzzled on how this will work with BIG.little btw. > >>> > >>> The rough idea is that for BIG.little the kernel must trap the > >>> ID registers at least (so that the vcpu seems consistent to the > >>> guest whether it's running on the big or the little core). For > >>> "-cpu host" the guest would see whatever is the most low-overhead > >>> for the kernel to provide (ie assuming the big and little CPUs > >>> are roughly-similar you could make -cpu host provide something > >>> that looks to the guest like the big CPU and don't have to trap > >>> quite as much as you would for providing a vcpu that wasn't the > >>> same as either the big or little one). > >> > >> So -cpu host in this case wouldn't actually expose the host CPU 1:1, but instead a cortex-a15 even when it's run on an a7 BIG.little core. I see. > >> > > Yes, from the discussion we've had the whole picture just becomes to > > blurry when you start presenting multiple different CPUs to the guest > > and there's really no need to that I'm aware of. > > > > In fact the -cpu host case fits quite nicely with this state of mind; > > the kernel is free to decide based on the specific hardware and config > > on which it's running how to handle VMs on BL. > > So why not have a vm ioctl to fetch the "best match" vcpu type? I don't like the idea of adding any awareness of a "host" type to the normal vcpu creation process. > > That's actually what I suggested initially. I'm not really a QEMU expert, but I think Peter already answered this question: he doesn't want to support hundreds of CPU models in QEMU just to be able to run KVM when it's not necessary. If his argument holds in that you can support -cpu host without having a model for that specific cpu in QEMU, then indeed it is a strong argument, and we have the problem with ARMv8 already, and this goes a long way to solve that. No? _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
