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)
Regards,
Anthony Liguori
The device tree is about the guest view of devices.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
