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 934031F7586 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-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-659--gwHuHgOPO-IZXeRj3cOEw-1; Wed, 06 Aug 2025 17:42:18 -0400 X-MC-Unique: -gwHuHgOPO-IZXeRj3cOEw-1 X-Mimecast-MFC-AGG-ID: -gwHuHgOPO-IZXeRj3cOEw_1754516538 Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-741a4bfe2aaso27045a34.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=YXMmEP98/Aifyw6jxEBZvNdWR6YHHEnWC6fvxjR9HIKi7xSZcr3c/6+eSRky049M0K jjcttlkT57Z8CaFLgcTqhSd8ONkkxNA7gh4Kooc0EHznDruOVMfKqbn0qN+d0X4/rjxm SABdrr4nNl0kLbPFuteUi9aBammuX+xU+8AraOr53PIHCRa0KKTDVPcVu8nxhc+0QHl2 bI+/5DGOmYqZrL0QQQsZn4RH7eg8HeIc2yqzijfaHFWs/SGeThNQDED0EgY83ifFinlh 8cMn2bXtpL2LbP3Ur5jxEiQrCAXuNsZBWusIqEkd7tlOb5i6EmXoCJmgSeFymZnYcZop ujOA== X-Forwarded-Encrypted: i=1; AJvYcCV8WasKP8+HjpamsZo6xDrV76xS5snR9YU/QOWgg2NQ5Rp5tSzFUfwDHhXWnhlIZlvxh8Rln/4escu4yQ==@vger.kernel.org X-Gm-Message-State: AOJu0YxlKktKjQTlBEA/8+7oyl0N1CPWoDGTsN5m46hlGOE5LJRD5DnE FfKMTH/1dUDa/MQ6fmOkzVKONcdsEZc3g0JmVwN4CsTW80sYi7QTHNhIZsqHwdloO33o9PzKT6G 76wOX72SE6brwTpitn4VUq7stWsRDQGEFQzjzbBLCqKH39d594Q/uBmImpL0eezFP X-Gm-Gg: ASbGncuQCczQOw1lzFy1YMoKJYgklJJOZ5MaLpYbGFTYFTGiD+FpXhwKlYIHnKZn+0o VgpNQ/Z0dQ9v6iyMdhKW7IyzELBQKfZAkWCt7FZWT54jegNiyVWAGzcqN9h/qHsNKivl+3D+lyO fZrDmEbGzbQ7Wvs9KUI8FVjI+5AhihQWeZfrlbuKWKbZnsYiHOQQGF3yvASKM6CIjaN2dQBVCPr Is/6T1WaKvliCJh06O+PCIQ0UAxeUxXV9Kxb1k3EvZ4Vyrm8dlAcfbUZnGL69RL6IqNDiFAdd6I Qvx4Ib5TF7PyvZ1R/bOxD1ZsmnBJfTOcNJbwAAyaU8s= X-Received: by 2002:a05:6830:3145:b0:741:a217:720f with SMTP id 46e09a7af769-7430e2000b0mr942380a34.2.1754516537625; 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-media@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