RE: [PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

From: Tian, Kevin
Date: Tue Aug 11 2020 - 23:35:56 EST

> From: Alex Williamson <alex.williamson@xxxxxxxxxx>
> Sent: Wednesday, August 12, 2020 10:36 AM
> On Wed, 12 Aug 2020 01:58:00 +0000
> "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> > >
> > > I'll also remind folks that LPC is coming up in just a couple short
> > > weeks and this might be something we should discuss (virtually)
> > > in-person. uconf CfPs are currently open. </plug> Thanks,
> > >
> >
> > Yes, LPC is a good place to reach consensus. btw I saw there is
> > already one VFIO topic called "device assignment/sub-assignment".
> > Do you think whether this can be covered under that topic, or
> > makes more sense to be a new one?
> All the things listed in the CFP are only potential topics to get ideas
> flowing, there is currently no proposal to talk about sub-assignment.
> I'd suggest submitting separate topics for each and if we run into time
> constraints we can ask that they might be combined together. Thanks,

title: Criteria of using VFIO mdev (vs. userspace DMA)

VFIO mdev provides a framework for subdevice assignment and reuses
existing VFIO uAPI to handle common passthrough-related requirements.
However, subdevice (e.g. ADI defined in Intel Scalable IOV) might not be
a PCI endpoint (e.g. just a work queue), thus requires some degree of
emulation/mediation in kernel to fit into VFIO device API. Then there is
a concern on putting emulation in kernel and how to judge abuse of
mdev framework by simply using it as an easy path to hook into
virtualization stack. An associated open is about differentiating mdev
from userspace DMA framework (such as uacce), and whether building
passthrough features on top of userspace DMA framework is a better
choice than using mdev.