Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19127FF05@SHSMSX101.ccr.corp.intel.com>
Date:   Wed, 25 Jul 2018 06:19:46 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     'Jean-Philippe Brucker' <jean-philippe.brucker@....com>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>, Joerg Roedel <joro@...tes.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Kirti Wankhede <kwankhede@...dia.com>
CC:     "Raj, Ashok" <ashok.raj@...el.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Sun, Yi Y" <yi.y.sun@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>
Subject: RE: [RFC PATCH 03/10] iommu/vt-d: Allocate groups for mediated
 devices

> From: Tian, Kevin
> Sent: Wednesday, July 25, 2018 10:16 AM
> 
[...]
> >
> > There is another way: as we're planning to add a generic pasid_alloc()
> > function to the IOMMU API, the mdev module itself could allocate a
> > default PASID for each mdev by calling pasid_alloc() on the mdev's
> > parent, and then do map()/unmap() with that PASID. This way we don't
> > have to add IOMMU ops to the mdev bus, everything can still be done
> > using the ops of the parent. And IOMMU drivers "only" have to
> implement
> > PASID ops, which will be reused by drivers other than mdev.
> 
> yes, PASID is more general abstraction than mdev. However there is
> one problem. Please note with new scalable mode now PASID is not
> used just for SVA. You can do 1st-level, 2nd-level and nested in PASID
> granularity, meaning each PASID can be bound to an unique iommu
> domain. However today IOMMU driver allows only one iommu_domain
> per device. If we simply install allocated PASID to parent device, we
> should also remove that iommu_domain limitation. Is it the way that
> we want to pursue?
> 
> mdev avoids such problem as it introduces a separate device...

another thing to think about is to simplify the caller logic. It would
be good to have consistent IOMMU APIs cross PCI device and 
mdev, for common VFIO operations e.g. map/unmap, iommu_
attach_group, etc. If we need special version ops with PASID, it 
brings burden to VFIO and other IOMMU clients...

For IOMMU-capable mdev, there are two use cases which have 
been talked so far:

1) mdev with PASID-granular DMA isolation
2) mdev inheriting RID from parent device (no sharing)

1) is what this RFC is currently for. 2) is what Alex concerned 
which is not covered in RFC yet.

In my mind, an ideal design is like below:

a) VFIO provides an interface for parent driver to specify 
whether a mdev is IOMMU capable, with flag to indicate 
whether it's PASID-granular or RID-inherit;

b) Once an IOMMU-capable mdev is created, VFIO treats it no
different from normal physical devices, using exactly same 
IOMMU APIs to operate (including future SVA). VFIO doesn't 
care whether PASID or RID will be used in hardware;

c) IOMMU driver then handle RID/PASID difference internally, 
based on its own configuration and mdev type.

To support above goal, I feel a new device handle is a nice fit 
to represent mdev within IOMMU driver, with same set of 
capabilities as observed on its parent device.

Jean, maybe I didn't fully understand your proposal. Can you
elaborate whether above goal can be achieved with it?

Thanks
Kevin

Powered by blists - more mailing lists