Re: [PATCH 2/2][RFC] KVM: Emulate MSI-X table and PBA in kernel

Michael S. Tsirkin
2011-01-02T13:58:26Z

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