netdev - [LSF/MM/BPF proposal]: Physr discussion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y8v+qVZ8OmodOCQ9@nvidia.com>
Date:   Sat, 21 Jan 2023 11:03:05 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     lsf-pc@...ts.linuxfoundation.org, linux-mm@...ck.org,
        iommu@...ts.linux.dev, linux-rdma@...r.kernel.org
Cc:     Matthew Wilcox <willy@...radead.org>,
        Christoph Hellwig <hch@....de>,
        Joao Martins <joao.m.martins@...cle.com>,
        John Hubbard <jhubbard@...dia.com>,
        Logan Gunthorpe <logang@...tatee.com>,
        Ming Lei <ming.lei@...hat.com>, linux-block@...r.kernel.org,
        netdev@...r.kernel.org, linux-mm@...ck.org,
        linux-rdma@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        nvdimm@...ts.linux.dev
Subject: [LSF/MM/BPF proposal]: Physr discussion

I would like to have a session at LSF to talk about Matthew's
physr discussion starter:

 https://lore.kernel.org/linux-mm/YdyKWeU0HTv8m7wD@casper.infradead.org/

I have become interested in this with some immediacy because of
IOMMUFD and this other discussion with Christoph:

 https://lore.kernel.org/kvm/4-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com/

Which results in, more or less, we have no way to do P2P DMA
operations without struct page - and from the RDMA side solving this
well at the DMA API means advancing at least some part of the physr
idea.

So - my objective is to enable to DMA API to "DMA map" something that
is not a scatterlist, may or may not contain struct pages, but can
still contain P2P DMA data. From there I would move RDMA MR's to use
this new API, modify DMABUF to export it, complete the above VFIO
series, and finally, use all of this to add back P2P support to VFIO
when working with IOMMUFD by allowing IOMMUFD to obtain a safe
reference to the VFIO memory using DMABUF. From there we'd want to see
pin_user_pages optimized, and that also will need some discussion how
best to structure it.

I also have several ideas on how something like physr can optimize the
iommu driver ops when working with dma-iommu.c and IOMMUFD.

I've been working on an implementation and hope to have something
draft to show on the lists in a few weeks. It is pretty clear there
are several interesting decisions to make that I think will benefit
from a live discussion.

Providing a kernel-wide alternative to scatterlist is something that
has general interest across all the driver subsystems. I've started to
view the general problem rather like xarray where the main focus is to
create the appropriate abstraction and then go about transforming
users to take advatange of the cleaner abstraction. scatterlist
suffers here because it has an incredibly leaky API, a huge number of
(often sketchy driver) users, and has historically been very difficult
to improve.

The session would quickly go over the current state of whatever the
mailing list discussion evolves into and an open discussion around the
different ideas.

Thanks,
Jason