Re: [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running KVM

[Christoffer Dall]

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 <address@hidden> 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?