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

[Alex Williamson <alex.williamson@redhat.com>]

On Wed, 2010-10-20 at 17:26 +0200, Avi Kivity wrote:
> On 10/20/2010 05:22 PM, Alex Williamson wrote:
> > On Wed, 2010-10-20 at 17:17 +0200, Avi Kivity wrote:
> > >  On 10/20/2010 03:43 PM, Michael S. Tsirkin wrote:
> > >  >  >   >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.
> > >  >  >   >
> > >  >  >
> > >  >  >   But if we emulate the entire msix bar in vfio, that's not needed, right?
> > >  >
> > >  >  Yes, I think it is. How does kvm know which interrupt to inject?
> > >  >  Either vfio needs to pass that info to qemu and qemu would pass it
> > >  >  to kvm, or vfio would have some way to pass that info to kvm
> > >  >  directly.
> > >
> > >  Wait.  We can't emulate the BAR in vfio, we have to emulate it in kvm
> > >  where we emulate the write instruction.  We then need to tell vfio,
> > >  perhaps via userspace, that masking state has changed.
> > >
> > >  Seems very intrusive.
> >
> > We wouldn't direct map the vector table or pending bits, so we could
> > trap and emulate in qemu, which could then call into reads/writes in
> > vfio.
> >
> 
> That's 100% unintrusive for kvm, but that's what we do today, which is 
> deemed too slow.
> 
> Another option is to fake an interrupt remapping device and do a direct 
> map.  Will those older guests recognize and use it?  I imagine not.

Nope, I think it's a non-starter to think anything but the latest
current guests will have support for that.

Alex