Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments

[Alexander Graf]

On 11.01.2011, at 15:09, Anthony Liguori wrote:

> On 01/11/2011 08:06 AM, Alexander Graf wrote:
>> On 11.01.2011, at 15:00, Anthony Liguori wrote:
>> 
>>   
>>> On 01/11/2011 03:01 AM, Avi Kivity wrote:
>>>     
>>>> On 01/10/2011 10:23 PM, Anthony Liguori wrote:
>>>>       
>>>>>>> I don't see how ioapic, pit, or pic have a system scope.
>>>>>>>             
>>>>>> They are not bound to any CPU like the APIC which you may have in mind.
>>>>>>           
>>>>> And none of the above interact with KVM.
>>>>>         
>>>> They're implemented by kvm.  What deeper interaction do you have in mind?
>>>>       
>>> The emulated ioapic/pit/pic do not interact with KVM at all.
>>> 
>>> The KVM versions should be completely separate devices.
>>> 
>>>     
>>>>       
>>>>> They may be replaced by KVM but if you look at the PIT, this is done by 
>>>>> having two distinct devices.  The KVM specific device can (and should) be 
>>>>> instantiated with kvm_state.
>>>>> 
>>>>> The way the IOAPIC/APIC/PIC is handled in qemu-kvm is nasty.  The kernel 
>>>>> devices are separate devices and that should be reflected in the device 
>>>>> tree.
>>>>>         
>>>> I don't see why.  Those are just two different implementations for the 
>>>> same guest visible device.
>>>>       
>>> Right, they should appear the same to the guest but the fact that they're 
>>> two different implementations should be reflected in the device tree.
>>> 
>>>     
>>>>  It's like saying IDE should be seen differently if it's backed by qcow2 
>>>> or qed.
>>>>       
>>> No, it's not at all.
>>> 
>>> Advantages of separating KVM devices:
>>> 
>>> 1) it becomes very clear what functionality is handled in the kernel verses 
>>> in userspace (you can actually look at the code and tell)
>>> 
>>> 2) a user can explicitly create either the emulated version of the device 
>>> or the in-kernel version of the device (no need for -no-kvm-irqchip)
>>> 
>>> 3) a user can pass parameters directly to the in-kernel version of the 
>>> device that are different from the userspace version (like selecting 
>>> different interrupt catch-up methods)
>>>     
>> Disadvantages:
>> 
>> 1) you lose migration / savevm between KVM and non-KVM VMs
>>   
> 
> This doesn't work today and it's never worked.  KVM exposes things that TCG 
> cannot emulate (like pvclock).

Those cases simply shouldn't exist and hurt us (or at least me). I had exactly 
the pvclock issue with xenner. Xenner can't do proper timekeeping in emulation 
mode. So implementing an emulated pvclock implementation is (pretty low) on my 
todo list.

> Even as two devices, nothing prevents it from working.  Both devices just 
> have to support each other's savevm format.  If they use the same code, it 
> makes it very easy.  Take a look at how the KVM PIT is implemented for an 
> example of this.

If that's all it takes, fine. It makes it pretty hard to enforce, but I guess 
we can get away with that :).

Making devices separate basically hurts abstraction. I don't see any use case 
where we should have a KVM device without emulation equivalent. For the CPU we 
also think of KVM as an accelerator instead of a separate device, no? :)


Alex