Re: Mask bit support's API

Avi Kivity
2010-11-23T14:06:24Z

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