[Top][All Lists]
[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:24:05 +0100 |
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
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, (continued)
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Alexander Graf, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments,
Alexander Graf <=
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Anthony Liguori, 2011/01/10
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Jan Kiszka, 2011/01/10
- Re: [Qemu-devel] Re: [PATCH 26/35] kvm: Eliminate KVMState arguments, Avi Kivity, 2011/01/11
[Qemu-devel] [PATCH 25/35] kvm: x86: Drop MCE MSRs write back restrictions, Marcelo Tosatti, 2011/01/06
[Qemu-devel] [PATCH] kvm: x86: Fix build in absence of KVM_CAP_ASYNC_PF, Jan Kiszka, 2011/01/27