On Tue, 4 Nov 2025 14:23:24 +0530 Meghana Malladi wrote:
> > I tried honoring Jakub's comment to avoid freeing the rx memory wherever
> > necessary.
> >
> > "In case of icssg driver, freeing the rx memory is necessary as the
> > rx descriptor memory is owned by the cppi dma controller and can be
> > mapped to a single memory model (pages/xdp buffers) at a given time.
> > In order to remap it, the memory needs to be freed and reallocated."
>
> Just to make sure we are on the same page, does the above explanation
> make sense to you or do you want me to make any changes in this series
> for v5 ?
No. Based on your reply below you seem to understand what is being
asked, so you're expected to do it.
> >> I think you should:
> >> - stop the H/W from processing incoming packets,
> >> - spool all the pending packets
> >> - attach/detach the xsk_pool
> >> - refill the ring
> >> - re-enable the H/W
> >
> > Current implementation follows the same sequence:
> > 1. Does a channel teardown -> stop incoming traffic
> > 2. free the rx descriptors from free queue and completion queue -> spool
> > all pending packets/descriptors
> > 3. attach/detach the xsk pool
> > 4. allocate rx descriptors and fill the freeq after mapping them to the
> > correct memory buffers -> refill the ring
> > 5. restart the NAPI - re-enable the H/W to recv the traffic
> >
> > I am still working on skipping 2 and 4 steps but this will be a long
> > shot. Need to make sure all corner cases are getting covered. If this
> > approach looks doable without causing any regressions I might post it as
> > a followup patch later in the future.
On Tue, Nov 04, 2025 at 11:19:43AM -0800, Nicolin Chen wrote:
> On Sun, Nov 02, 2025 at 10:00:48AM +0200, Leon Romanovsky wrote:
> > Changelog:
> > v6:
> > * Fixed wrong error check from pcim_p2pdma_init().
> > * Documented pcim_p2pdma_provider() function.
> > * Improved commit messages.
> > * Added VFIO DMA-BUF selftest.
> > * Added __counted_by(nr_ranges) annotation to struct vfio_device_feature_dma_buf.
> > * Fixed error unwind when dma_buf_fd() fails.
> > * Document latest changes to p2pmem.
> > * Removed EXPORT_SYMBOL_GPL from pci_p2pdma_map_type.
> > * Moved DMA mapping logic to DMA-BUF.
> > * Removed types patch to avoid dependencies between subsystems.
> > * Moved vfio_pci_dma_buf_move() in err_undo block.
> > * Added nvgrace patch.
>
> I have verified this v6 using Jason's iommufd dmabuf branch:
> https://github.com/jgunthorpe/linux/commits/iommufd_dmabuf/
>
> by drafting a QEMU patch on top of Shameer's vSMMU v5 series:
> https://github.com/nicolinc/qemu/commits/wip/iommufd_dmabuf/
>
> with that, I see GPU BAR memory be correctly fetched in the QEMU:
> vfio_region_dmabuf Device 0009:01:00.0, region "0009:01:00.0 BAR 0", offset: 0x0, size: 0x1000000
> vfio_region_dmabuf Device 0009:01:00.0, region "0009:01:00.0 BAR 2", offset: 0x0, size: 0x44f00000
> vfio_region_dmabuf Device 0009:01:00.0, region "0009:01:00.0 BAR 4", offset: 0x0, size: 0x17a0000000
Great thanks! This means we finally have a solution to that follow_pfn
lifetime problem in type 1! What a long journey :)
For those following along this same flow will be used with KVM to
allow it to map VFIO as well. Confidential Compute will require this
because some arches can't put confidential MMIO (or RAM) into a VMA.
Jason