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