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

Michael S. Tsirkin
2010-10-20T15:20:06Z

On Wed, Oct 20, 2010 at 09:07:12AM -0600, Alex Williamson wrote:
> On Wed, 2010-10-20 at 16:46 +0200, Michael S. Tsirkin wrote:
> > 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.
>
> What does KVM add to the masking? VFIO owns the interrupt handler,
> which can decide if the interrupt is masked and set a pending bit in an
> emulated PBA, or if unmasked it sends it to qemu via eventfd. For KVM,
> I think we'd just augment that last bit to relay the interrupt to KVM
> for direct guest injection.

Right. MAsking in KVM is good for old style assignment and for vhost-net.

> > > 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?
>
> That would be possible too, only trouble is then we have QEMU
> intercepting and interpreting the write as well as VFIO intercepting and
> interpreting the write.
> If VFIO is only masking off the mask bit,
> that'd be pretty trivial though.
>
> Alex

I just mean write() instead of an ioctl()

--
MST