Re: [LSF/MM/BPF proposal]: Physr discussion
On Tue, Feb 28, 2023 at 12:59:41PM -0800, T.J. Mercier wrote: > On Sat, Jan 21, 2023 at 7:03 AM Jason Gunthorpe wrote: > > > > I would like to have a session at LSF to talk about Matthew's > > physr discussion starter: > > > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@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. [..] I got fairly far along this and had to put it aside for some other tasks, but here is what I came up with so far: https://github.com/jgunthorpe/linux/commits/rlist PCI/P2PDMA: Do not store bus_off in the pci_p2pdma_map_state PCI/P2PDMA: Split out the information about the providing device from pgmap PCI/P2PDMA: Move the DMA API helpers to p2pdma_provider lib/rlist: Introduce range list lib/rlist: Introduce rlist cpu range iterator PCI/P2PDMA: Store the p2pdma_provider structs in an xarray lib/rlist: Introduce rlist_dma dma: Add DMA direct support for rlist mapping dma: Generic rlist dma_map_ops dma: Add DMA API support for mapping a rlist_cpu to a rlist_dma iommu/dma: Implement native rlist dma_map_ops dma: Use generic_dma.*_rlist in simple dma_map_ops implementations dma: Use generic_dma.*_rlist when map_sg just does map_page for n=1 dma: Use generic_dma.*_rlist when iommu_area_alloc() is used dma/dummy: Add rlist s390/dma: Use generic_dma.*_rlist mm/gup: Create a wrapper for pin_user_pages to return a rlist dmabuf: WIP DMABUF exports the backing memory through rcpu RDMA/mlx5: Use rdma_umem_for_each_dma_block() RMDA/mlx: Use rdma_umem_for_each_dma_block() instead of sg_dma_address RDMA/mlx5: Use the length of the MR not the umem RDMA/umem: Add ib_umem_length() instead of open coding RDMA: Add IB DMA API wrappers for rlist RDMA: Switch ib_umem to rlist cover-letter: RFC Create an alternative to scatterlist in the DMA API It is huge and scary. It is not quite nice enough to post but should be an interesting starting point for LSF/MM. At least it broadly shows all the touching required and why this is such a nasty problem. The draft cover letter explaining what the series does: cover-letter: RFC Create an alternative to scatterlist in the DMA API This was kicked off by Matthew with his phyr idea from this thread: https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/ Hwoevr, 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_...@nvidia.com/ Which results in, more or less, we have no way to do P2P DMA operations without struct page. This becomes complicated when we touch RDMA which highly relies on scatterlist for its internal implementations, so being unable to use scatterlist to store only dma_addr_t's means RDMA needs a complete scatterlist replacement that can. 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 physical addresses. With this tool, transform the RDMA subystem to use the new DMA API and then go into DMABUF and stop creating scatterlists without any CPU pages. From that point we could implement DMABUF in VFIO (as above) and use the DMABUF to feed the MMIO pages into IOMMUFD to restore the PCI P2P support in VMs withotu creating the follow_pte security problem that VFIO has. After going through the thread again, and making some sketches, I've come up with this suggestion as a path forward, explored very roughly in this RFC: 1) Create something I've called a 'range list CPU iterator'. This is an API that abstractly iterates over CPU physical memory ranges. It has useful helpers to iterate over things in 'struct page/folio *', physical ranges, copy to/from, and so on It has the necessary extra bits beyond the physr sketch to support P2P in the DMA API based on what was done for the pgmap based stuff. ie we need to know the provider of the non-struct page memory to get the struct device to compute the p2p distance and compute the pci_offset. The immediate idea is this is an iterator, not a data structure. So it can iterate over different kinds of storage. This frees us from having to immediatly consolidate all the different storage schemes in the
Re: [LSF/MM/BPF proposal]: Physr discussion
On Sat, Jan 21, 2023 at 7:03 AM Jason Gunthorpe wrote: > > I would like to have a session at LSF to talk about Matthew's > physr discussion starter: > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@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 > Hi, I'm interested in participating in this discussion!
Re: [Lsf-pc] [LSF/MM/BPF proposal]: Physr discussion
On Mon, Jan 23, 2023 at 12:50:52PM -0800, Dan Williams wrote: > Matthew Wilcox wrote: > > On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote: > > > Jason Gunthorpe via Lsf-pc wrote: > > > > I would like to have a session at LSF to talk about Matthew's > > > > physr discussion starter: > > > > > > > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@nvidia.com/ > > > > > > I think this is a worthwhile discussion. My main hangup with 'struct > > > page' elimination in general is that if anything needs to be allocated > > > > You're the first one to bring up struct page elimination. Neither Jason > > nor I have that as our motivation. > > Oh, ok, then maybe I misread the concern in the vfio discussion. I > thought the summary there is debating the ongoing requirement for > 'struct page' for P2PDMA? The VFIO problem is we need a unique pgmap at 4k granuals (or maybe smaller, technically), tightly packed, because VFIO exposes PCI BAR space that can be sized in such small amounts. So, using struct page means some kind of adventure in the memory hotplug code to allow tightly packed 4k pgmaps. And that is assuming that every architecture that wants to support VFIO supports pgmap and memory hot plug. I was just told that s390 doesn't, that is kind of important.. If there is a straightforward way to get a pgmap into VFIO then I'd do that and give up this quest :) I've never been looking at this from the angle of eliminating struct page, but from the perspective of allowing the DMA API to correctly do scatter/gather IO to non-struct page P2P memory because I *can't* get a struct page for it. Ie make dma_map_resource() better. Make P2P DMABUF work properly. This has to come along with a different way to store address ranges because the basic datum that needs to cross all the functional boundaries we have is an address range list. My general current sketch is we'd allocate some 'DMA P2P provider' structure analogous to the MEMORY_DEVICE_PCI_P2PDMA pgmap and a single provider would cover the entire MMIO aperture - eg the providing device's MMIO BAR. This is enough information for the DMA API to do its job. We get this back either by searching an interval treey thing on the physical address or by storing it directly in the address range list. Jason
Re: [LSF/MM/BPF proposal]: Physr discussion
On Mon, Jan 23, 2023 at 04:36:25AM +, Matthew Wilcox wrote: > On Sat, Jan 21, 2023 at 11:03:05AM -0400, Jason Gunthorpe wrote: > > I would like to have a session at LSF to talk about Matthew's > > physr discussion starter: > > > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/ > > I'm definitely interested in discussing phyrs (even if you'd rather > pronounce it "fizzers" than "fires" ;-) I'm also interested in this discussion. With my accent it will be фыр, though ;-) > > 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. > > Cool! Here's my latest noodlings: > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/phyr > > Just the top two commits; the other stuff is unrelated. Shakeel has > also been interested in this. > >
Re: [LSF/MM/BPF proposal]: Physr discussion
在 2023/1/21 23:03, Jason Gunthorpe 写道: I would like to have a session at LSF to talk about Matthew's physr discussion starter: https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@nvidia.com/ I read through the above patches. I am interested in the dma-buf. Zhu Yanjun 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
Re: [LSF/MM/BPF proposal]: Physr discussion
On 1/23/23 11:47, Bart Van Assche wrote: > On 1/23/23 05:44, Jason Gunthorpe wrote: >> I've gone from quite a different starting point - I've been working >> DMA API upwards, so what does the dma_map_XX look like, what APIs do >> we need to support the dma_map_ops implementations to iterate/etc, how >> do we form and return the dma mapped list, how does P2P, with all the >> checks, actually work, etc. These help inform what we want from the >> "phyr" as an API. > > I'm interested in this topic. I'm wondering whether eliminating > scatterlists could help to make the block layer faster. > > Thanks, > > Bart. > I think it will be very interesting to discuss this in great detail and come up with the plan. +1 from me. -ck
Re: [Lsf-pc] [LSF/MM/BPF proposal]: Physr discussion
On Mon, Jan 23, 2023 at 12:50:52PM -0800, Dan Williams wrote: > Matthew Wilcox wrote: > > On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote: > > > Jason Gunthorpe via Lsf-pc wrote: > > > > I would like to have a session at LSF to talk about Matthew's > > > > physr discussion starter: > > > > > > > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@nvidia.com/ > > > > > > I think this is a worthwhile discussion. My main hangup with 'struct > > > page' elimination in general is that if anything needs to be allocated > > > > You're the first one to bring up struct page elimination. Neither Jason > > nor I have that as our motivation. > > Oh, ok, then maybe I misread the concern in the vfio discussion. I > thought the summary there is debating the ongoing requirement for > 'struct page' for P2PDMA? My reading of that thread is that while it started out that way, it became more about "So what would a good interface be for doing this". And Jason's right, he and I are approaching this from different directions. My concern is from the GUP side where we start out by getting a folio (which we know is physically contiguous) and decomposing it into pages. Then we aggregate all those pages together which are physically contiguous and stuff them into a bio_vec. After that, I lose interest; I was planning on having DMA mapping interfaces which took in an array of phyr and spat out scatterlists. Then we could shrink the scatterlist by removing page_link and offset, leaving us with only dma_address, length and maybe flags.
Re: [Lsf-pc] [LSF/MM/BPF proposal]: Physr discussion
Matthew Wilcox wrote: > On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote: > > Jason Gunthorpe via Lsf-pc wrote: > > > I would like to have a session at LSF to talk about Matthew's > > > physr discussion starter: > > > > > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@nvidia.com/ > > > > I think this is a worthwhile discussion. My main hangup with 'struct > > page' elimination in general is that if anything needs to be allocated > > You're the first one to bring up struct page elimination. Neither Jason > nor I have that as our motivation. Oh, ok, then maybe I misread the concern in the vfio discussion. I thought the summary there is debating the ongoing requirement for 'struct page' for P2PDMA?
Re: [Lsf-pc] [LSF/MM/BPF proposal]: Physr discussion
On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote: > Jason Gunthorpe via Lsf-pc wrote: > > I would like to have a session at LSF to talk about Matthew's > > physr discussion starter: > > > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@nvidia.com/ > > I think this is a worthwhile discussion. My main hangup with 'struct > page' elimination in general is that if anything needs to be allocated You're the first one to bring up struct page elimination. Neither Jason nor I have that as our motivation. But there are reasons why struct page is a bad data structure, and Xen proves that you don't need to have such a data structure in order to do I/O. > When I read "general interest across all the driver subsystems" it is > hard not to ask "have all possible avenues to enable 'struct page' been > exhausted?" Yes, we should definitely expend yet more resources chasing a poor implementation.
Re: [LSF/MM/BPF proposal]: Physr discussion
On 1/23/23 05:44, Jason Gunthorpe wrote: I've gone from quite a different starting point - I've been working DMA API upwards, so what does the dma_map_XX look like, what APIs do we need to support the dma_map_ops implementations to iterate/etc, how do we form and return the dma mapped list, how does P2P, with all the checks, actually work, etc. These help inform what we want from the "phyr" as an API. I'm interested in this topic. I'm wondering whether eliminating scatterlists could help to make the block layer faster. Thanks, Bart.
RE: [Lsf-pc] [LSF/MM/BPF proposal]: Physr discussion
Jason Gunthorpe via Lsf-pc wrote: > I would like to have a session at LSF to talk about Matthew's > physr discussion starter: > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@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_...@nvidia.com/ I think this is a worthwhile discussion. My main hangup with 'struct page' elimination in general is that if anything needs to be allocated to describe a physical address for other parts of the kernel to operate on it, why not a 'struct page'? There are of course several difficulties allocating a 'struct page' array, but I look at subsection support and the tail page space optimization work as evidence that some of the pain can be mitigated, what more needs to be done? I also think this is somewhat of a separate consideration than replacing a bio_vec with phyr where that has value independent of the mechanism used to manage phys_addr_t => dma_addr_t. > 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. When I read "general interest across all the driver subsystems" it is hard not to ask "have all possible avenues to enable 'struct page' been exhausted?" > 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. Sounds good to me.
Re: [LSF/MM/BPF proposal]: Physr discussion
On Mon, Jan 23, 2023 at 04:36:25AM +, Matthew Wilcox wrote: > > 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. > > Cool! Here's my latest noodlings: > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/phyr > > Just the top two commits; the other stuff is unrelated. Shakeel has > also been interested in this. I've gone from quite a different starting point - I've been working DMA API upwards, so what does the dma_map_XX look like, what APIs do we need to support the dma_map_ops implementations to iterate/etc, how do we form and return the dma mapped list, how does P2P, with all the checks, actually work, etc. These help inform what we want from the "phyr" as an API. The DMA API is the fundamental reason why everything has to use scatterlist - it is the only way to efficiently DMA map anything more than a few pages. If we can't solve that then everything else is useless, IMHO. If we have an agreement on DMA API then things like converting RDMA to use it and adding it to DMABUF are comparatively straightforward. There are 24 implementations of dma_map_ops, so my approach is to try to build a non-leaky 'phyr' API that doesn't actually care how the physical ranges are stored, separates CPU and DMA and then use that to get all 24 implementations. With a good API we can fiddle with the exact nature of the phyr as we like. I've also been exploring the idea that with a non-leaking API we don't actually need to settle on one phyr to rule them all. bio_vec can stay as is, but become directly dma mappable, rdma/drm can use something better suited to the page list use cases (eg 8 bytes/entry not 16), and a non-leaking API can multiplex these different memory layouts and allow one dma_map_ops implementation to work on both. Thanks, Jason
Re: [LSF/MM/BPF proposal]: Physr discussion
On Sat, Jan 21, 2023 at 11:03:05AM -0400, Jason Gunthorpe wrote: > I would like to have a session at LSF to talk about Matthew's > physr discussion starter: > > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/ I'm definitely interested in discussing phyrs (even if you'd rather pronounce it "fizzers" than "fires" ;-) > 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. Cool! Here's my latest noodlings: https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/phyr Just the top two commits; the other stuff is unrelated. Shakeel has also been interested in this.
[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/ydykweu0htv8m...@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_...@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
