On 01/02/2011 01:51 PM, Michael S. Tsirkin wrote:
> > > >I don't see how userspace can send interrupts with this > >interface unfortunately. We also need irqfd support ... > > Sure we'll need additions to that interface. What I suggested is 1. an ioctl to map phy address + size to table id 2. a new gsi type with a table id + entry number. If we have that, assigned devices, virtio and vhost-net can work mostly as is, with just the mask bits accelerated.
Ok. Please adopt this patch and send a series that does this. I'd like to see the whole thing working.
> What about vhost-net and vfio? I thought that they could emulate > the mask bits: > > - KVM_MMIOFD(vmfd, mmio_range, fd1, fd2) associates an mmio range with an fd > - writel(mmio_range) or readl(mmio_range) from the guest causes a > command to be written to fd1 > - for readl(), read from fd2 to see the result (works nicely for > "pci read flushes posted writes") > > this allows interesting stuff to be implemented in separate > processes, threads, or kernel modules. This could work. Some thought needs to be given to how we make sure that an appropriate type of file is passed in. Maybe using a netlink based connector for this a good idea?
Why do we care what type of file is passed? We just write there, and whatever is on the other side needs to handle it.
OTOH if we have MSIX mask bit emulation in kvm anyway, using it makes sense ...
Yeah, except I'm not sure how the current proposal can interface with vfio. So we'll have two interfaces, until we vfio takes over completely.
-- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
