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

[Alexander Graf]

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.


Alex