lkml.org 
[lkml]   [2020]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH RFC 00/15] Add VFIO mediated device support and IMS support for the idxd driver.
    Date
    > From: Jason Gunthorpe
    > Sent: Wednesday, April 22, 2020 7:55 AM
    >
    > On Tue, Apr 21, 2020 at 04:33:46PM -0700, Dave Jiang wrote:
    > > The actual code is independent of the stage 2 driver code submission that
    > adds
    > > support for SVM, ENQCMD(S), PASID, and shared workqueues. This code
    > series will
    > > support dedicated workqueue on a guest with no vIOMMU.
    > >
    > > A new device type "mdev" is introduced for the idxd driver. This allows the
    > wq
    > > to be dedicated to the usage of a VFIO mediated device (mdev). Once the
    > work
    > > queue (wq) is enabled, an uuid generated by the user can be added to the
    > wq
    > > through the uuid sysfs attribute for the wq. After the association, a mdev
    > can
    > > be created using this UUID. The mdev driver code will associate the uuid
    > and
    > > setup the mdev on the driver side. When the create operation is successful,
    > the
    > > uuid can be passed to qemu. When the guest boots up, it should discover a
    > DSA
    > > device when doing PCI discovery.
    >
    > I'm feeling really skeptical that adding all this PCI config space and
    > MMIO BAR emulation to the kernel just to cram this into a VFIO
    > interface is a good idea, that kind of stuff is much safer in
    > userspace.
    >
    > Particularly since vfio is not really needed once a driver is using
    > the PASID stuff. We already have general code for drivers to use to
    > attach a PASID to a mm_struct - and using vfio while disabling all the
    > DMA/iommu config really seems like an abuse.

    Well, this series is for virtualizing idxd device to VMs, instead of supporting
    SVA for bare metal processes. idxd implements a hardware-assisted
    mediated device technique called Intel Scalable I/O Virtualization, which
    allows each Assignable Device Interface (ADI, e.g. a work queue) tagged
    with an unique PASID to ensure fine-grained DMA isolation when those
    ADIs are assigned to different VMs. For this purpose idxd utilizes the VFIO
    mdev framework and IOMMU aux-domain extension. Bare metal SVA will
    be enabled for idxd later by using the general SVA code that you mentioned.
    Both paths will co-exist in the end so there is no such case of disabling
    DMA/iommu config.

    Thanks
    Kevin

    >
    > A /dev/idxd char dev that mmaps a bar page and links it to a PASID
    > seems a lot simpler and saner kernel wise.
    >
    > > The mdev utilizes Interrupt Message Store or IMS[3] instead of MSIX for
    > > interrupts for the guest. This preserves MSIX for host usages and also
    > allows a
    > > significantly larger number of interrupt vectors for guest usage.
    >
    > I never did get a reply to my earlier remarks on the IMS patches.
    >
    > The concept of a device specific addr/data table format for MSI is not
    > Intel specific. This should be general code. We have a device that can
    > use this kind of kernel capability today.
    >
    > Jason

    \
     
     \ /
      Last update: 2020-04-22 02:54    [W:3.595 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site