Re: [PATCH 0/8][v2] MSI-X mask emulation support for assigned device

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Oct 20, 2010 at 08:47:14AM -0600, Alex Williamson wrote:
> On Wed, 2010-10-20 at 12:44 +0200, Michael S. Tsirkin wrote:
> > On Wed, Oct 20, 2010 at 11:51:01AM +0200, Avi Kivity wrote:
> > >  On 10/20/2010 10:26 AM, Sheng Yang wrote:
> > > >Here is v2.
> > > >
> > > >Changelog:
> > > >
> > > >v1->v2
> > > >
> > > >The major change from v1 is I've added the in-kernel MSI-X mask emulation
> > > >support, as well as adding shortcuts for reading MSI-X table.
> > > >
> > > >I've taken Michael's advice to use mask/unmask directly, but unsure about
> > > >exporting irq_to_desc() for module...
> > > >
> > > >Also add flush_work() according to Marcelo's comments.
> > > >
> > > 
> > > Any performance numbers?  What are the affected guests?  just RHEL
> > > 4, or any others?
> > 
> > Likely any old linux.
> > 
> > > Alex, Michael, how would you do this with vfio?
> > 
> > With current VFIO we would catch mask writes in qemu and
> > call a KVM ioctl. We would also need an ioctl to retrieve
> > pending bits long term.
> 
> Ugh, no.  VFIO us currently independent of KVM.  I'd like to keep it
> that way.  We'll need to optimize interrupt injection and eoi via KVM,
> but it should only be a performance optimization, not a functional
> requirement.

So ideally masking would be optimizeable too.

> It would probably make sense to request a mask/unmask ioctl in VFIO for
> MSI-X, then perhaps the pending bits would only support read/write (no
> mmap), so we could avoid an ioctl there.

Why not mask/unmask with a write?

> > I think that it is unfortunate that we need to do this in userspace
> > while rest of configuration is done in kernel.
> > I would be much happier with userspace simply forwarding
> > everything to VFIO, so emulation does not have to
> > be split. That would be a clean interface: just mmap
> > MSIX BAR and forget about it.
> > 
> > If instead of eventfd we had a file descriptor that can pass vector
> > information from vfio to kvm and back, that would fix it,
> > as we would not need to set us GSIs at all,
> > and not need for userspace to handle MSIX specially.
> 
> Sounds good except that I'd like to get away from forcing device
> assignment interfaces into KVM.
> 
> Alex

How to split up the modules is an implementation detail though.

-- 
MST