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

[Alexander Graf]

On 14.08.2013, at 19:39, Christoffer Dall wrote:

> 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?

That's up for QEMU to decide. With the "fetch and push" model we can support 
both flavors from user space. It also makes the kernel side more reproducible 
and obvious. There's simply no way to add hacks like "If I'm a -cpu host type 
do xxx" in KVM, because KVM never knows that it is running -cpu host.


Alex