qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments
Date: Tue, 11 Jan 2011 15:06:40 +0100

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

I'm not saying this is unsolvable, but it's certainly something that bothers me 
:). Some sort of meta-device for KVM implemented devices and emulated devices 
would be nice. That device would then be the one state gets saved/restored from.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]