Re: [PATCH] PCI/P2PDMA: Avoid returning a provider for non_mappable_bars

[Matt Evans]

Hi Leon,

On 22/04/2026 16:19, Leon Romanovsky wrote:
> On Wed, Apr 22, 2026 at 03:22:53PM +0100, Matt Evans wrote:
> > Hi Leon,
> >
> > On 21/04/2026 20:49, Leon Romanovsky wrote:
> > > On Tue, Apr 21, 2026 at 10:43:51AM -0700, Matt Evans wrote:
> > > > Extend pcim_p2pdma_provider()'s checks to exclude functions that have
> > > > pdev->non_mappable_bars set.
> > > >
> > > > Consumers such as VFIO were previously able to map these for access by
> > > > the CPU or P2P.  Update the comment on non_mappable_bars to show it
> > > > refers to any access, not just userspace CPU access.
> > > >
> > > > Fixes: 372d6d1b8ae3c ("PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation")
> > >
> > > I don't object to the patch, but this Fixes line doesn't look correct.
> > > non_mappable_bars applies only to s390, which doesn't support p2p. That
> > > wasn't prevented before 372d6d1b8ae3c refactoring too.
> >
> > Thanks; I'd chosen that commit as it adds the function that the additional
> > test is being added to.
>
> Can I suggest slightly different solution?
> If CONFIG_..._S390 is set, we will unset CONFIG_PCI_P2PDMA and pcim_p2pdma_provider()
> will be compiled to return NULL, without changing non_mappable_bars
> description.

Where we got to in

   https://lore.kernel.org/kvm/20260415181623.1021090-1-mattev@xxxxxxxx/

was that non_mappable_bars could be used in future for non-s390 quirks, 
i.e. s390 is the current (but potentially not only) user.  Secondly, it 
isn't a P2P-specific issue because in

   https://lore.kernel.org/kvm/20260416131815.2729131-1-mattev@xxxxxxxx/

I'm aiming to add mmap() support to VFIO DMABUFs, which (without a fix 
like this) would allow CPU access too.


Thanks,


Matt