On Sun, Jan 02, 2011 at 03:34:21PM +0200, Avi Kivity wrote: > 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. Me too. > 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
