lkml.org 
[lkml]   [2021]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 11/20] iommu/iommufd: Add IOMMU_IOASID_ALLOC/FREE
    On Sun, Sep 19, 2021 at 02:38:39PM +0800, Liu Yi L wrote:
    > This patch adds IOASID allocation/free interface per iommufd. When
    > allocating an IOASID, userspace is expected to specify the type and
    > format information for the target I/O page table.
    >
    > This RFC supports only one type (IOMMU_IOASID_TYPE_KERNEL_TYPE1V2),
    > implying a kernel-managed I/O page table with vfio type1v2 mapping
    > semantics. For this type the user should specify the addr_width of
    > the I/O address space and whether the I/O page table is created in
    > an iommu enfore_snoop format. enforce_snoop must be true at this point,
    > as the false setting requires additional contract with KVM on handling
    > WBINVD emulation, which can be added later.
    >
    > Userspace is expected to call IOMMU_CHECK_EXTENSION (see next patch)
    > for what formats can be specified when allocating an IOASID.
    >
    > Open:
    > - Devices on PPC platform currently use a different iommu driver in vfio.
    > Per previous discussion they can also use vfio type1v2 as long as there
    > is a way to claim a specific iova range from a system-wide address space.
    > This requirement doesn't sound PPC specific, as addr_width for pci devices
    > can be also represented by a range [0, 2^addr_width-1]. This RFC hasn't
    > adopted this design yet. We hope to have formal alignment in v1 discussion
    > and then decide how to incorporate it in v2.

    I think the request was to include a start/end IO address hint when
    creating the ios. When the kernel creates it then it can return the
    actual geometry including any holes via a query.

    > - Currently ioasid term has already been used in the kernel (drivers/iommu/
    > ioasid.c) to represent the hardware I/O address space ID in the wire. It
    > covers both PCI PASID (Process Address Space ID) and ARM SSID (Sub-Stream
    > ID). We need find a way to resolve the naming conflict between the hardware
    > ID and software handle. One option is to rename the existing ioasid to be
    > pasid or ssid, given their full names still sound generic. Appreciate more
    > thoughts on this open!

    ioas works well here I think. Use ioas_id to refer to the xarray
    index.

    > Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
    > drivers/iommu/iommufd/iommufd.c | 120 ++++++++++++++++++++++++++++++++
    > include/linux/iommufd.h | 3 +
    > include/uapi/linux/iommu.h | 54 ++++++++++++++
    > 3 files changed, 177 insertions(+)
    >
    > diff --git a/drivers/iommu/iommufd/iommufd.c b/drivers/iommu/iommufd/iommufd.c
    > index 641f199f2d41..4839f128b24a 100644
    > +++ b/drivers/iommu/iommufd/iommufd.c
    > @@ -24,6 +24,7 @@
    > struct iommufd_ctx {
    > refcount_t refs;
    > struct mutex lock;
    > + struct xarray ioasid_xa; /* xarray of ioasids */
    > struct xarray device_xa; /* xarray of bound devices */
    > };
    >
    > @@ -42,6 +43,16 @@ struct iommufd_device {
    > u64 dev_cookie;
    > };
    >
    > +/* Represent an I/O address space */
    > +struct iommufd_ioas {
    > + int ioasid;

    xarray id's should consistently be u32s everywhere.

    Many of the same prior comments repeated here

    Jason

    \
     
     \ /
      Last update: 2021-09-21 19:45    [W:4.097 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site