Re: Mask bit support's API

[Avi Kivity <avi@redhat.com>]

On 11/23/2010 03:57 PM, Yang, Sheng wrote:
> >  >
> >  >  Yeah, but won't be included in this patchset.
> >
> >  What API changes are needed?  I'd like to see the complete API.
>
> I am not sure about it. But I suppose the structure should be the same? In fact
> it's pretty hard for me to image what's needed for virtio in the future,
> especially there is no such code now. I really prefer to deal with assigned device
> and virtio separately, which would make the work much easier. But seems you won't
> agree on that.

First, I don't really see why the two cases are different (but I don't 
do a lot in this space).  Surely between you and Michael, you have all 
the information?

Second, my worry is a huge number of ABI variants that come from 
incrementally adding features.  I want to implement bigger chunks of 
functionality.  So I'd like to see all potential users addressed, at 
least from the ABI point of view if not the implementation.

> >  The API needs to be compatible with the pending bit, even if we don't
> >  implement it now.  I want to reduce the rate of API changes.
>
> This can be implemented by this API, just adding a flag for it. And I would still
> take this into consideration in the next API purposal.

Shouldn't kvm also service reads from the pending bitmask?

> >
> >  So instead of
> >
> >  - guest reads/writes msix
> >  - kvm filters mmio, implements some, passes others to userspace
> >
> >  we have
> >
> >  - guest reads/writes msix
> >  - kvm implements all
> >  - some writes generate an additional notification to userspace
>
> I suppose we don't need to generate notification to userspace? Because every
> read/write is handled by kernel, and userspace just need interface to kernel to
> get/set the entry - and well, does userspace need to do it when kernel can handle
> all of them? Maybe not...

We could have the kernel handle addr/data writes by setting up an 
internal interrupt routing.  A disadvantage is that more work is needed 
if we emulator interrupt remapping in qemu.

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