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

[Matt Evans <mattev@meta.com>]

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@meta.com/

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@meta.com/

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


Thanks,


Matt