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

[Anthony Liguori]

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.