From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9346B221299 for ; Wed, 6 Aug 2025 21:42:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754516542; cv=none; b=auWyl2nJ/WfgytxED7+r9Z17hx7LRg7T5w+kqjQD5+gClZz7ETirGtH7gTEqP4YVETsQVGy/KDCdrm6CAggqN2b3NusXhosN4erDBSzFhf9HTq+hHJJ1/huTKbbTARvYTgT/7jjjPya1ZHvC4W6ZuK3vZXVhPaKKLammHwfHNqw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754516542; c=relaxed/simple; bh=u5wJkgayWtoH/wDIjbh042FOJb9qmim8x01zf6tfYcg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DSSRi2Lkdvs7nscFk2DziudsyX566EXT68cq6qPlicqiiU2BLYzKIbdp6zJC8NPdyiUeLfdQ4X06akw9o811WzRQXGF8DeRBOnRoIvLmIs0TgH9K/SD5QyI+MH8r+X0LO8fepfhP4sMx3L2QC765GSyW+Fxfcm6RgFkwgl7nQmE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=gzoSR8q7; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gzoSR8q7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1754516539; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UEyeHS4HV3rZ/wSqVLFMAOzjnboPPP41DAzDFsrqTZs=; b=gzoSR8q7cp3nMlecMWMhJvFMf1kygaOcadqfgj2VkVNaMVd7iwHT1E3ei2y2LmDw0s9UVY uoOn56HrUqB7y7D59UxDMrEfkyInqLXp9t1IVnuOa/owH4pVHY/oKRy3chkomxVQ/nZQ0F MrIGUYRUM3AJUJHcn9zCm37L3PwSPW0= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-615-UCEMrTbfMjqACtzV8CJ6Lg-1; Wed, 06 Aug 2025 17:42:18 -0400 X-MC-Unique: UCEMrTbfMjqACtzV8CJ6Lg-1 X-Mimecast-MFC-AGG-ID: UCEMrTbfMjqACtzV8CJ6Lg_1754516538 Received: by mail-ot1-f72.google.com with SMTP id 46e09a7af769-741a4bfe2aaso27046a34.1 for ; Wed, 06 Aug 2025 14:42:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754516537; x=1755121337; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UEyeHS4HV3rZ/wSqVLFMAOzjnboPPP41DAzDFsrqTZs=; b=Z1Tfam//3I3OW0axMEJjnftdu5meAEdf/DSGHmhAxRkDXw2laAR66IQM/V8GH5rVIm c+W7cnnfDifqK+CRCmg5o0JK8X2p1hfpCzOKyRC7z2oY7F9KSYcV+YaUTPbxU6UZIQxV 9A0wvr3B+jj+ewFTTeZAIhwjyy0wikl0jnoDITeNtpnz2FsbaRE/NewEkdtPkR7qffNi c9IaDt1lo07r5ixQbt60GVPzgHCK+yXS7RZRPGcrqg0UQh1FiXDam2TCBZMnYwxRM++M oNatZ3Fj5wcVyf4R4I1gvZKMfuQs38EXQS9wAO8ftBfdr9Q0IIEig712tOPlFJUB8yUr Exdg== X-Forwarded-Encrypted: i=1; AJvYcCVHXTG47OraqkNoTQFgQU5Vzopn/VA9Bh+j7AbAmcP17xL+N0UwpKJKAMwPc/QOh/DwMFbsvkjRJwXg6g==@vger.kernel.org X-Gm-Message-State: AOJu0YznWYnNGGsBT5Pdai7NV74JFg0r/HUtlKj05LxflCPhy2wMIU4r 2rCRsGlDg8YeZa6sPeofKvogPPO6Q3haP8xpVwyUoX5RAEo2GLLQrI9ZVNvWeZFjHY3gqtODB2L XMWLU1hWqdWbwOTdeqODk9bgRxCmAG0Gu1bV0tpjVqftzFzl+qvZ3GpdvKvuP9tc1 X-Gm-Gg: ASbGncvBfgb98lWz2yjrrkmFVOpQO1JoPyeWA6g/TaNnUhksi14jdzhtjvkP1Cjlm6I 8S0lMP2hk4xOz4RK52mSU8+Y8pY9FOp0BsCqWyOuTphmU8bXtkANaZGBRRUDqz5GfJf5rKpuktz 36cRKtq3RqFCR1mLPCieW6X8NCFEGg2Q/U7MTgaoHgycz0fxC6sECYcFpt8r15IrfRP/LmIv8SQ X1q0mYn4Id7a9VbwJNaXGHxhsMd5oFruscyflBp1AKNb4THParhfdj0eyXPfJRBmdYVwprkucTp 2FzcqsuGO2hCfgG4CNZPplbVzGtdgnobvZmZoOUCi10= X-Received: by 2002:a05:6830:3145:b0:741:a217:720f with SMTP id 46e09a7af769-7430e2000b0mr942358a34.2.1754516537604; Wed, 06 Aug 2025 14:42:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH5QU5ZQlpYSxfTPMUFCWfqP/wnHyNw5oOZqDg/+tC9OzPbWJoK2cj/jTsdC9+aUwDUHNbnjQ== X-Received: by 2002:a05:6830:3145:b0:741:a217:720f with SMTP id 46e09a7af769-7430e2000b0mr942353a34.2.1754516537077; Wed, 06 Aug 2025 14:42:17 -0700 (PDT) Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-74186cc4e1bsm3606901a34.21.2025.08.06.14.42.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Aug 2025 14:42:16 -0700 (PDT) Date: Wed, 6 Aug 2025 15:42:14 -0600 From: Alex Williamson To: Leon Romanovsky Cc: Leon Romanovsky , Jason Gunthorpe , Andrew Morton , Bjorn Helgaas , Christian =?UTF-8?B?S8O2bmln?= , Christoph Hellwig , dri-devel@lists.freedesktop.org, iommu@lists.linux.dev, Jens Axboe , Joerg Roedel , kvm@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, Logan Gunthorpe , Marek Szyprowski , Robin Murphy , Sumit Semwal , Vivek Kasireddy , Will Deacon Subject: Re: [PATCH v1 04/10] PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation Message-ID: <20250806154214.1c2618e8.alex.williamson@redhat.com> In-Reply-To: References: Organization: Red Hat Precedence: bulk X-Mailing-List: linux-block@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 4 Aug 2025 16:00:39 +0300 Leon Romanovsky wrote: > From: Leon Romanovsky > > Refactor the PCI P2PDMA subsystem to separate the core peer-to-peer DMA > functionality from the optional memory allocation layer. This creates a > two-tier architecture: > > The core layer provides P2P mapping functionality for physical addresses > based on PCI device MMIO BARs and integrates with the DMA API for > mapping operations. This layer is required for all P2PDMA users. > > The optional upper layer provides memory allocation capabilities > including gen_pool allocator, struct page support, and sysfs interface > for user space access. > > This separation allows subsystems like VFIO to use only the core P2P > mapping functionality without the overhead of memory allocation features > they don't need. The core functionality is now available through the > new pci_p2pdma_enable() function that returns a p2pdma_provider > structure. > > Signed-off-by: Leon Romanovsky > --- > drivers/pci/p2pdma.c | 118 ++++++++++++++++++++++++++----------- > include/linux/pci-p2pdma.h | 5 ++ > 2 files changed, 89 insertions(+), 34 deletions(-) > > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c > index 176a99232fdca..24a6c8ff88520 100644 > --- a/drivers/pci/p2pdma.c > +++ b/drivers/pci/p2pdma.c > @@ -25,11 +25,12 @@ struct pci_p2pdma { > struct gen_pool *pool; > bool p2pmem_published; > struct xarray map_types; > + struct p2pdma_provider mem; > }; > > struct pci_p2pdma_pagemap { > struct dev_pagemap pgmap; > - struct p2pdma_provider mem; > + struct p2pdma_provider *mem; > }; > > static struct pci_p2pdma_pagemap *to_p2p_pgmap(struct dev_pagemap *pgmap) > @@ -204,7 +205,7 @@ static void p2pdma_page_free(struct page *page) > struct pci_p2pdma_pagemap *pgmap = to_p2p_pgmap(page_pgmap(page)); > /* safe to dereference while a reference is held to the percpu ref */ > struct pci_p2pdma *p2pdma = rcu_dereference_protected( > - to_pci_dev(pgmap->mem.owner)->p2pdma, 1); > + to_pci_dev(pgmap->mem->owner)->p2pdma, 1); > struct percpu_ref *ref; > > gen_pool_free_owner(p2pdma->pool, (uintptr_t)page_to_virt(page), > @@ -227,44 +228,82 @@ static void pci_p2pdma_release(void *data) > > /* Flush and disable pci_alloc_p2p_mem() */ > pdev->p2pdma = NULL; > - synchronize_rcu(); > + if (p2pdma->pool) > + synchronize_rcu(); > + xa_destroy(&p2pdma->map_types); > + > + if (!p2pdma->pool) > + return; > > gen_pool_destroy(p2pdma->pool); > sysfs_remove_group(&pdev->dev.kobj, &p2pmem_group); > - xa_destroy(&p2pdma->map_types); > } > > -static int pci_p2pdma_setup(struct pci_dev *pdev) > +/** > + * pci_p2pdma_enable - Enable peer-to-peer DMA support for a PCI device > + * @pdev: The PCI device to enable P2PDMA for > + * > + * This function initializes the peer-to-peer DMA infrastructure for a PCI > + * device. It allocates and sets up the necessary data structures to support > + * P2PDMA operations, including mapping type tracking. > + */ > +struct p2pdma_provider *pci_p2pdma_enable(struct pci_dev *pdev) > { > - int error = -ENOMEM; > struct pci_p2pdma *p2p; > + int ret; > + > + p2p = rcu_dereference_protected(pdev->p2pdma, 1); > + if (p2p) > + /* PCI device was "rebound" to the driver */ > + return &p2p->mem; > > p2p = devm_kzalloc(&pdev->dev, sizeof(*p2p), GFP_KERNEL); > if (!p2p) > - return -ENOMEM; > + return ERR_PTR(-ENOMEM); > > xa_init(&p2p->map_types); > + p2p->mem.owner = &pdev->dev; > + /* On all p2p platforms bus_offset is the same for all BARs */ > + p2p->mem.bus_offset = > + pci_bus_address(pdev, 0) - pci_resource_start(pdev, 0); But not all devices implement BAR0, nor is BAR0 necessarily in the memory space, wouldn't this calculation be wrong if BAR0 were unimplemented or an IO BAR? Even within memory BARs I can imagine different translations for 32 vs 64 bit, prefetch vs non-prefetch, but per the comment I guess we're excluding those. Thanks, Alex