Re: [Qemu-devel] Re: [PATCH v2 9/9] Add -kvm option

[Avi Kivity]

On 10/08/2009 04:33 PM, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 10/08/2009 04:23 PM, Anthony Liguori wrote:
> > > > > What I'd like to see in the interim is a kvm specific machine type 
> > > > > that's defaulted to if kvm is enabled.  I think this would be 
> > > > > useful not only for enabling things like in-kernel apic, but also 
> > > > > for selecting a default cpu model.
> > > >
> > > > We should make a distinction between guest-visible changes and 
> > > > accelerators like kvm-irqchip and vhost.
> > >
> > > They are different device models that happen to implement the same 
> > > guest-visible device. 
> >
> > I think this separation is artificial.  From both the guest's view 
> > and the user's view, there's no difference between qemu ioapic and 
> > kvm ioapic (modulo bugs).  To me this indicates they're the same device.
>
> That's not always been true historically.  For instance, the in-kernel 
> pit does interrupt catchup whereas the userspace pit does not.

That's a bug in the userspace pit :)

I'm worried about things like 'info pit' needing dual implementations.

> > We'll have the same problem with vhost-net, only there the 
> > duplication will be much greater if we split the implementation.
>
> I'd rather not treat vhost-net like a device model and instead treat 
> it like a -net backend.  If we can bounce requests through userspace 
> (and we can), we should be able to use it for any device model.  In 
> the case of virtio-net, we should be able to short-circuit things such 
> that we don't have to go through userspace.  It's admittedly very 
> hairy without a point-to-point net abstraction.

Interesting idea.  I think it'll be hairy even with a point-to-point net 
abstraction, but it's worth trying.

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