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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
