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

[Avi Kivity]

On 01/11/2011 04:00 PM, 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.

How can they "not interact" with kvm if they're implemented by kvm?

I really don't follow here.

> The KVM versions should be completely separate devices.

Why?

> > 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.

Why?

To move beyond single-word questions, what is the purpose of the device 
tree?  In my mind, it reflects the virtual hardware.  What's important 
is that we have a PIC, virtio network adapter, and IDE disk.  Not that 
they're backed by kvm, vhost-net, and qcow2.

> >   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)

How something is implemented is not important, certainly not important 
enough to expose to the user as an monitor or live migration ABI.

> 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)

-device ioapic,model=kernel vs. -device kvm-ioapic?

Is it really important to do that? 110% of the time we want the kernel 
irqchips.  The remaining -10% are only used for testing.

> 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)

-device pit,model=qemu,catchup=slew

error: catchup=slew not supported in this model

I'm not overly concerned about the implementation part.  Though I think 
it's better to have a single implementation with kvm acting as an 
accelerator, having it the other way is no big deal.  What I am worried 
about is exposing it as a monitor and migration ABI.  IMO the only 
important thing is the spec that the device implements, not what piece 
of code implements it.

--
error compiling committee.c: too many arguments to function