Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On 2022-07-06 01:04, Greg Kroah-Hartman wrote: > On Wed, Jul 06, 2022 at 08:51:27AM +0200, Christoph Hellwig wrote: >> On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote: >>> The current version does it through a char device, but that requires >>> creating a simple_fs and anon_inode for teardown on driver removal, plus >>> a bunch of hooks through the driver that exposes it (NVMe, in this case) >>> to set this all up. >>> >>> Christoph is suggesting a sysfs interface which could potentially avoid >>> the anon_inode and all of the extra hooks. It has some significant >>> benefits and maybe some small downsides, but I wouldn't describe it as >>> horrid. >> >> Yeah, I don't think is is horrible, it fits in with the resource files >> for the BARs, and solves a lot of problems. Greg, can you explain >> what would be so bad about it? > > As you mention, you will have to pass different things down into sysfs > in order for that to be possible. If it matches the resource files like > we currently have today, that might not be that bad, but it still feels > odd to me. Let's see an implementation and a Documentation/ABI/ entry > first though. I'll work something up in the coming weeks. Thanks, Logan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Wed, Jul 06, 2022 at 08:51:27AM +0200, Christoph Hellwig wrote: > On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote: > > The current version does it through a char device, but that requires > > creating a simple_fs and anon_inode for teardown on driver removal, plus > > a bunch of hooks through the driver that exposes it (NVMe, in this case) > > to set this all up. > > > > Christoph is suggesting a sysfs interface which could potentially avoid > > the anon_inode and all of the extra hooks. It has some significant > > benefits and maybe some small downsides, but I wouldn't describe it as > > horrid. > > Yeah, I don't think is is horrible, it fits in with the resource files > for the BARs, and solves a lot of problems. Greg, can you explain > what would be so bad about it? As you mention, you will have to pass different things down into sysfs in order for that to be possible. If it matches the resource files like we currently have today, that might not be that bad, but it still feels odd to me. Let's see an implementation and a Documentation/ABI/ entry first though. thanks, greg k-h ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote: > The current version does it through a char device, but that requires > creating a simple_fs and anon_inode for teardown on driver removal, plus > a bunch of hooks through the driver that exposes it (NVMe, in this case) > to set this all up. > > Christoph is suggesting a sysfs interface which could potentially avoid > the anon_inode and all of the extra hooks. It has some significant > benefits and maybe some small downsides, but I wouldn't describe it as > horrid. Yeah, I don't think is is horrible, it fits in with the resource files for the BARs, and solves a lot of problems. Greg, can you explain what would be so bad about it? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On 2022-07-05 11:42, Greg Kroah-Hartman wrote: > On Tue, Jul 05, 2022 at 11:32:23AM -0600, Logan Gunthorpe wrote: >> >> >> On 2022-07-05 11:21, Greg Kroah-Hartman wrote: >>> On Tue, Jul 05, 2022 at 06:50:39PM +0200, Christoph Hellwig wrote: [note for the newcomers, this is about allowing mmap()ing the PCIe P2P memory from the generic PCI P2P code through sysfs, and more importantly how to revoke it on device removal] >>> >>> We allow mmap on PCIe config space today, right? Why is this different >>> from what pci_create_legacy_files() does today? >>> On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote: > We might be able to. I'm not sure. I'll have to figure out how to find > that inode from the p2pdma code. I haven't found an obvious interface to > do that. I think the right way to approach this would be a new sysfs API that internally calls unmap_mapping_range internally instead of exposing the inode. I suspect that might actually be the right thing to do for iomem_inode as well. >>> >>> Why do we need something new and how is this any different from the PCI >>> binary files I mention above? We have supported PCI hotplug for a very >>> long time, do the current PCI binary sysfs files not work properly with >>> mmap and removing a device? >> >> The P2PDMA code allocates and hands out struct pages to userspace that >> are backed with ZONE_DEVICE memory from a device's BAR. This is quite >> different from the existing binary files mentioned above which neither >> support struct pages nor allocation. > > Why would you want to do this through a sysfs interface? that feels > horrid... The current version does it through a char device, but that requires creating a simple_fs and anon_inode for teardown on driver removal, plus a bunch of hooks through the driver that exposes it (NVMe, in this case) to set this all up. Christoph is suggesting a sysfs interface which could potentially avoid the anon_inode and all of the extra hooks. It has some significant benefits and maybe some small downsides, but I wouldn't describe it as horrid. Logan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 11:32:23AM -0600, Logan Gunthorpe wrote: > > > On 2022-07-05 11:21, Greg Kroah-Hartman wrote: > > On Tue, Jul 05, 2022 at 06:50:39PM +0200, Christoph Hellwig wrote: > >> [note for the newcomers, this is about allowing mmap()ing the PCIe > >> P2P memory from the generic PCI P2P code through sysfs, and more > >> importantly how to revoke it on device removal] > > > > We allow mmap on PCIe config space today, right? Why is this different > > from what pci_create_legacy_files() does today? > > > >> On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote: > >>> We might be able to. I'm not sure. I'll have to figure out how to find > >>> that inode from the p2pdma code. I haven't found an obvious interface to > >>> do that. > >> > >> I think the right way to approach this would be a new sysfs API > >> that internally calls unmap_mapping_range internally instead of > >> exposing the inode. I suspect that might actually be the right thing > >> to do for iomem_inode as well. > > > > Why do we need something new and how is this any different from the PCI > > binary files I mention above? We have supported PCI hotplug for a very > > long time, do the current PCI binary sysfs files not work properly with > > mmap and removing a device? > > The P2PDMA code allocates and hands out struct pages to userspace that > are backed with ZONE_DEVICE memory from a device's BAR. This is quite > different from the existing binary files mentioned above which neither > support struct pages nor allocation. Why would you want to do this through a sysfs interface? that feels horrid... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On 2022-07-05 11:21, Greg Kroah-Hartman wrote: > On Tue, Jul 05, 2022 at 06:50:39PM +0200, Christoph Hellwig wrote: >> [note for the newcomers, this is about allowing mmap()ing the PCIe >> P2P memory from the generic PCI P2P code through sysfs, and more >> importantly how to revoke it on device removal] > > We allow mmap on PCIe config space today, right? Why is this different > from what pci_create_legacy_files() does today? > >> On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote: >>> We might be able to. I'm not sure. I'll have to figure out how to find >>> that inode from the p2pdma code. I haven't found an obvious interface to >>> do that. >> >> I think the right way to approach this would be a new sysfs API >> that internally calls unmap_mapping_range internally instead of >> exposing the inode. I suspect that might actually be the right thing >> to do for iomem_inode as well. > > Why do we need something new and how is this any different from the PCI > binary files I mention above? We have supported PCI hotplug for a very > long time, do the current PCI binary sysfs files not work properly with > mmap and removing a device? The P2PDMA code allocates and hands out struct pages to userspace that are backed with ZONE_DEVICE memory from a device's BAR. This is quite different from the existing binary files mentioned above which neither support struct pages nor allocation. Logan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 06:50:39PM +0200, Christoph Hellwig wrote: > [note for the newcomers, this is about allowing mmap()ing the PCIe > P2P memory from the generic PCI P2P code through sysfs, and more > importantly how to revoke it on device removal] We allow mmap on PCIe config space today, right? Why is this different from what pci_create_legacy_files() does today? > On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote: > > We might be able to. I'm not sure. I'll have to figure out how to find > > that inode from the p2pdma code. I haven't found an obvious interface to > > do that. > > I think the right way to approach this would be a new sysfs API > that internally calls unmap_mapping_range internally instead of > exposing the inode. I suspect that might actually be the right thing > to do for iomem_inode as well. Why do we need something new and how is this any different from the PCI binary files I mention above? We have supported PCI hotplug for a very long time, do the current PCI binary sysfs files not work properly with mmap and removing a device? thanks, greg k-h ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
[note for the newcomers, this is about allowing mmap()ing the PCIe P2P memory from the generic PCI P2P code through sysfs, and more importantly how to revoke it on device removal] On Tue, Jul 05, 2022 at 10:44:49AM -0600, Logan Gunthorpe wrote: > We might be able to. I'm not sure. I'll have to figure out how to find > that inode from the p2pdma code. I haven't found an obvious interface to > do that. I think the right way to approach this would be a new sysfs API that internally calls unmap_mapping_range internally instead of exposing the inode. I suspect that might actually be the right thing to do for iomem_inode as well. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On 2022-07-05 10:43, Christoph Hellwig wrote: > On Tue, Jul 05, 2022 at 10:41:52AM -0600, Logan Gunthorpe wrote: >> Using sysfs means we don't need all the messy callbacks from the nvme >> driver, which is a plus. But I'm not sure how we'd get or unmap the >> mapping of a sysfs file or avoid the anonymous inode. Seems with the >> existing PCI resources, it uses an bin_attribute->f_mapping() callback >> to pass back the iomem_get_mapping() mapping on file open. >> revoke_iomem() is then used to nuke the VMAs. I don't think we can use >> the same infrastructure here as that would add a dependency on >> CONFIG_IO_STRICT_DEVMEM; which would be odd. And I'm not sure whether >> there is a better way. > > Why can't we do the revoke on the actual sysfs inode? We might be able to. I'm not sure. I'll have to figure out how to find that inode from the p2pdma code. I haven't found an obvious interface to do that. Logan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 10:41:52AM -0600, Logan Gunthorpe wrote: > Using sysfs means we don't need all the messy callbacks from the nvme > driver, which is a plus. But I'm not sure how we'd get or unmap the > mapping of a sysfs file or avoid the anonymous inode. Seems with the > existing PCI resources, it uses an bin_attribute->f_mapping() callback > to pass back the iomem_get_mapping() mapping on file open. > revoke_iomem() is then used to nuke the VMAs. I don't think we can use > the same infrastructure here as that would add a dependency on > CONFIG_IO_STRICT_DEVMEM; which would be odd. And I'm not sure whether > there is a better way. Why can't we do the revoke on the actual sysfs inode? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On 2022-07-05 10:12, Christoph Hellwig wrote: > On Tue, Jul 05, 2022 at 10:51:02AM -0300, Jason Gunthorpe wrote: >>> In fact I'm not even sure this should be a character device, it seems >>> to fit it way better with the PCI sysfs hierchacy, just like how we >>> map MMIO resources, which these are anyway. And once it is on sysfs >>> we do have a uniqueue inode and need none of the pseudofs stuff, and >>> don't need all the glue code in nvme either. >> >> Shouldn't there be an allocator here? It feels a bit weird that the >> entire CMB is given to a single process, it is a sharable resource, >> isn't it? > > Making the entire area given by the device to the p2p allocator available > to user space seems sensible to me. That is what the current series does, > and what a sysfs interface would do as well. Yes, I think Jason is assuming the sysfs file would behave like the existing mmio resource files where the process doing the mapping specifies the offset and length into the BAR. That is not what we want here, but I don't see why I don't see why we can't do the same thing in sysfs as we do with the char device with a bin_attribute->mmap() callback. mmapping the char device was convenient in user space, but it's not much more work to dig through sysfs and mmap an attribute from there. Using sysfs means we don't need all the messy callbacks from the nvme driver, which is a plus. But I'm not sure how we'd get or unmap the mapping of a sysfs file or avoid the anonymous inode. Seems with the existing PCI resources, it uses an bin_attribute->f_mapping() callback to pass back the iomem_get_mapping() mapping on file open. revoke_iomem() is then used to nuke the VMAs. I don't think we can use the same infrastructure here as that would add a dependency on CONFIG_IO_STRICT_DEVMEM; which would be odd. And I'm not sure whether there is a better way. Logan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 01:29:59PM -0300, Jason Gunthorpe wrote: > > Making the entire area given by the device to the p2p allocator available > > to user space seems sensible to me. That is what the current series does, > > and what a sysfs interface would do as well. > > That makes openning the mmap exclusive with the in-kernel allocator - > so it means opening the mmap fails if something else is using a P2P > page and once the mmap is open all kernel side P2P allocations will > fail? No. Just as in the current patchset you can mmap the file and will get len / PAGE_SIZE pages from the per-device p2pdma pool, or the mmap will fail if none are available. A kernel consumer (or multiple) can use other pages in the pool at the same time. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 06:12:40PM +0200, Christoph Hellwig wrote: > On Tue, Jul 05, 2022 at 10:51:02AM -0300, Jason Gunthorpe wrote: > > > In fact I'm not even sure this should be a character device, it seems > > > to fit it way better with the PCI sysfs hierchacy, just like how we > > > map MMIO resources, which these are anyway. And once it is on sysfs > > > we do have a uniqueue inode and need none of the pseudofs stuff, and > > > don't need all the glue code in nvme either. > > > > Shouldn't there be an allocator here? It feels a bit weird that the > > entire CMB is given to a single process, it is a sharable resource, > > isn't it? > > Making the entire area given by the device to the p2p allocator available > to user space seems sensible to me. That is what the current series does, > and what a sysfs interface would do as well. That makes openning the mmap exclusive with the in-kernel allocator - so it means opening the mmap fails if something else is using a P2P page and once the mmap is open all kernel side P2P allocations will fail? Which seems inelegant, I would expect the the mmap operation to request some pages from the P2P allocator and provide them to userspace so user and kernel workflows can co-exist using the same CMB. Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 10:51:02AM -0300, Jason Gunthorpe wrote: > > In fact I'm not even sure this should be a character device, it seems > > to fit it way better with the PCI sysfs hierchacy, just like how we > > map MMIO resources, which these are anyway. And once it is on sysfs > > we do have a uniqueue inode and need none of the pseudofs stuff, and > > don't need all the glue code in nvme either. > > Shouldn't there be an allocator here? It feels a bit weird that the > entire CMB is given to a single process, it is a sharable resource, > isn't it? Making the entire area given by the device to the p2p allocator available to user space seems sensible to me. That is what the current series does, and what a sysfs interface would do as well. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Tue, Jul 05, 2022 at 09:51:08AM +0200, Christoph Hellwig wrote: > But what also really matters here: I don't want every user that > wants to be able to mmap a character device to do all this work. > The layering is simply wrong, it needs some character device > based helpers, not be open code everywhere. I think alot (all?) cases would be happy if the inode was 1:1 with the cdev struct device. I suppose the cdev code would still have to create pseudo fs, but at least that is hidden. > In fact I'm not even sure this should be a character device, it seems > to fit it way better with the PCI sysfs hierchacy, just like how we > map MMIO resources, which these are anyway. And once it is on sysfs > we do have a uniqueue inode and need none of the pseudofs stuff, and > don't need all the glue code in nvme either. Shouldn't there be an allocator here? It feels a bit weird that the entire CMB is given to a single process, it is a sharable resource, isn't it? Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Wed, Jun 29, 2022 at 02:59:06PM -0300, Jason Gunthorpe wrote: > I've tried in the past, this is not a good idea. There is no way to > handle failures when a VMA is dup'd and if you rely on private_data > you almost certainly have to alloc here. > > Then there is the issue of making the locking work on invalidation > which is crazy ugly. > > > I was not a fan of the extra code for this either, but I was given to > > understand that it was the standard way to collect and cleanup VMAs. > > Christoph you tried tried to clean it once globally, what happened to > that? Al pointed out that there are various places that rely on having a separate file system. I might be able to go back to it and see if we could at least do it for some users. But what also really matters here: I don't want every user that wants to be able to mmap a character device to do all this work. The layering is simply wrong, it needs some character device based helpers, not be open code everywhere. In fact I'm not even sure this should be a character device, it seems to fit it way better with the PCI sysfs hierchacy, just like how we map MMIO resources, which these are anyway. And once it is on sysfs we do have a uniqueue inode and need none of the pseudofs stuff, and don't need all the glue code in nvme either. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Wed, Jun 29, 2022 at 10:00:09AM -0600, Logan Gunthorpe wrote: > > > > On 2022-06-29 00:48, Christoph Hellwig wrote: > > On Wed, Jun 15, 2022 at 10:12:32AM -0600, Logan Gunthorpe wrote: > >> A pseudo mount is used to allocate an inode for each PCI device. The > >> inode's address_space is used in the file doing the mmap so that all > >> VMAs are collected and can be unmapped if the PCI device is unbound. > >> After unmapping, the VMAs are iterated through and their pages are > >> put so the device can continue to be unbound. An active flag is used > >> to signal to VMAs not to allocate any further P2P memory once the > >> removal process starts. The flag is synchronized with concurrent > >> access with an RCU lock. > > > > Can't we come up with a way of doing this without all the pseudo-fs > > garbagage? I really hate all the overhead for that in the next > > nvme patch as well. > > I assume you still want to be able to unmap the VMAs on unbind and not > just hang? > > I'll see if I can come up with something to do the a similar thing using > vm_private data or some such. I've tried in the past, this is not a good idea. There is no way to handle failures when a VMA is dup'd and if you rely on private_data you almost certainly have to alloc here. Then there is the issue of making the locking work on invalidation which is crazy ugly. > I was not a fan of the extra code for this either, but I was given to > understand that it was the standard way to collect and cleanup VMAs. Christoph you tried tried to clean it once globally, what happened to that? All that is needed here is a way to get a unique inode for the PCI memory. Jason ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On 2022-06-29 00:48, Christoph Hellwig wrote: > On Wed, Jun 15, 2022 at 10:12:32AM -0600, Logan Gunthorpe wrote: >> A pseudo mount is used to allocate an inode for each PCI device. The >> inode's address_space is used in the file doing the mmap so that all >> VMAs are collected and can be unmapped if the PCI device is unbound. >> After unmapping, the VMAs are iterated through and their pages are >> put so the device can continue to be unbound. An active flag is used >> to signal to VMAs not to allocate any further P2P memory once the >> removal process starts. The flag is synchronized with concurrent >> access with an RCU lock. > > Can't we come up with a way of doing this without all the pseudo-fs > garbagage? I really hate all the overhead for that in the next > nvme patch as well. I assume you still want to be able to unmap the VMAs on unbind and not just hang? I'll see if I can come up with something to do the a similar thing using vm_private data or some such. I was not a fan of the extra code for this either, but I was given to understand that it was the standard way to collect and cleanup VMAs. Thanks for the reviews, Logan ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 20/21] PCI/P2PDMA: Introduce pci_mmap_p2pmem()
On Wed, Jun 15, 2022 at 10:12:32AM -0600, Logan Gunthorpe wrote: > A pseudo mount is used to allocate an inode for each PCI device. The > inode's address_space is used in the file doing the mmap so that all > VMAs are collected and can be unmapped if the PCI device is unbound. > After unmapping, the VMAs are iterated through and their pages are > put so the device can continue to be unbound. An active flag is used > to signal to VMAs not to allocate any further P2P memory once the > removal process starts. The flag is synchronized with concurrent > access with an RCU lock. Can't we come up with a way of doing this without all the pseudo-fs garbagage? I really hate all the overhead for that in the next nvme patch as well. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu