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.133.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 348C33093BF for ; Tue, 30 Sep 2025 16:08:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759248493; cv=none; b=r2uCojD+s2AN8jZi4THHCL22q0t4WOozYfyb1742eauZ+LFUi2v+VWfHXbrMgFLj/81oKXilpzFNf1JCojjpcVB8NYfogi8hFdCc65nYtFJ4ByXzpmrh2uipjkE5WBY3ozJId3CEzzBXOPfdAAjJij2D+nnDSsfLP6cieSHvvTE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759248493; c=relaxed/simple; bh=snlcpuhg9ToSlXPE+QrSoUGnOciOVCfFz6OxetVNkco=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DsntyTb3NJ/dRL8CoSAJSR6eDTTyqHG9ZZIiul7K1jPwLh83KwsZTV/OtH4E+ALoqn+LJ/sdNSwSQRV7hqNOtXSYBNNt+gqF14sTYRj4qAA/rA9oUquqSPz7NgVLJzwsBobREALOK82HP3Ewp7nUCKE2gjNb7rdIk/vhlUGhhQE= 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=iEaJoRjB; arc=none smtp.client-ip=170.10.133.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="iEaJoRjB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759248488; 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=wSk9NtZOWjVSHAXaMNsatYeAsaJr+OLKF/ipGZAl/7o=; b=iEaJoRjBA+qVbCTNV/oqwJexw0nqTxU26QfQUuNEGd/e5LwcG3SVI3iwX/J6+77+Hu96GU lCb1LtkdllqxxX7pyggvfazgHuKUXRj6PlAVNRCixumnbidCkdLMeK5OE+6jOxiiQ3zu9q fQqlXWepq5BkNzXq491VZo89wdOJVno= 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-96-3Bko1zhuM0yRZslPWW9vzA-1; Tue, 30 Sep 2025 12:08:04 -0400 X-MC-Unique: 3Bko1zhuM0yRZslPWW9vzA-1 X-Mimecast-MFC-AGG-ID: 3Bko1zhuM0yRZslPWW9vzA_1759248484 Received: by mail-ot1-f72.google.com with SMTP id 46e09a7af769-7b30885170eso1098970a34.1 for ; Tue, 30 Sep 2025 09:08:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759248483; x=1759853283; h=content-transfer-encoding:mime-version: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=wSk9NtZOWjVSHAXaMNsatYeAsaJr+OLKF/ipGZAl/7o=; b=N1faYW3V5OPwaLQ5SB3z0UZagfsOyDX9EVU/4StLhUdmpxZS/hSkEj7mIdhSGiKRAS CheSNpqxrI9XBVUz3aCBYsd+w8Sw1bPJeclIzfFZPfC5JjjIui3HAb1qS+jXxAqAMfGY cyiYxpA9aqgJMWmgFT0KzfIN62VZcfpOfngurs/l7QBXuUvxXySlyRNnuYEQaUbQz6xy 7tpiGRkxIdYTmYX8QlNikP5RGX4GhCUzKQ8HJ3WzJU1eLhEHGvOcbNRTMaxBMOorKcTB sifhQ1nTo2NAgdqMjwb4vLXH63vKmfrX5wdr3HPVddu87HI0s/E1SXzsayvfLgb8DUaH iHiw== X-Forwarded-Encrypted: i=1; AJvYcCWfI9/8KOWijbdCxdMPyJUWoCCJBxVeHOpy6GOjBKdJltnXeDgvn1XQjtUAsHRe1E7EB3gkas00Aa8M6j4=@vger.kernel.org X-Gm-Message-State: AOJu0YyxlYco352XmPYb0BUUyKob5/LBnAZMEo2BdUXVNwKqbW/0+wZk nz7EtcICp2icn7euBLW1NhYDFlK/pD/cu9KPL31X/YJkU7AU23Zlkdg0q6TM7JYHSo8XJjmYgAw aLGmpw0L0oRgknkRQkqbGTkFLR9Mhol6mwrY54aK6JK4JoYVvwi4/vOVK54c0uUiU7g== X-Gm-Gg: ASbGncuy64Y79nRrKnNi7U3vyar9/cz1Z5NA5j5g0ArZMxdBuS/BUy4NEYrhtKNon1a xVrU9LodY6jMcO0rOd0/A+FygrW1Q7UB97FDExlqWfJQr4WUFRzl5WTC1fRuy6v514LP3Ebl+Hg s3VxTE8b6s0OS0/H8fSfdix4Dyh16WgefjBOb9E8jBK/FfpqJ4Ol6SQwkqp0y8a8h+S1GoZ1RpC cv0t+aAn6V6bxXwBRfXxDuDGeImtattyjuhheQ3Oc7Rq0qTeUDll1P8sXZQXGMVemSmgayo3q4X IgKcxUeAsgCP9nvEd5UxTafbrzlaj9Qw9HyHybEJEiwlDJIk X-Received: by 2002:a05:6820:5082:b0:621:2845:6daa with SMTP id 006d021491bc7-64bb6545f8bmr113850eaf.0.1759248483596; Tue, 30 Sep 2025 09:08:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHJseUyrGoKfdwzuhrG64O9kfcQryt5nehwMqyr+Cc6sT4mD/DyY2Du1MoSsHbbw6RCv1mcDg== X-Received: by 2002:a05:6820:5082:b0:621:2845:6daa with SMTP id 006d021491bc7-64bb6545f8bmr113843eaf.0.1759248483252; Tue, 30 Sep 2025 09:08:03 -0700 (PDT) Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7b4c0e92da9sm1836631a34.26.2025.09.30.09.08.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Sep 2025 09:08:02 -0700 (PDT) Date: Tue, 30 Sep 2025 10:07:58 -0600 From: Alex Williamson To: Leon Romanovsky Cc: Jason Gunthorpe , Andrew Morton , Bjorn Helgaas , Christian =?UTF-8?B?S8O2bmln?= , 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 v4 07/10] vfio/pci: Add dma-buf export config for MMIO regions Message-ID: <20250930100758.1605d5a5.alex.williamson@redhat.com> In-Reply-To: <20250930075748.GF324804@unreal> References: <20250929151740.21f001e3.alex.williamson@redhat.com> <20250930075748.GF324804@unreal> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@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 Tue, 30 Sep 2025 10:57:48 +0300 Leon Romanovsky wrote: > On Mon, Sep 29, 2025 at 03:17:40PM -0600, Alex Williamson wrote: > > On Sun, 28 Sep 2025 17:50:17 +0300 > > Leon Romanovsky wrote: > > > > > From: Leon Romanovsky > > > > > > Add new kernel config which indicates support for dma-buf export > > > of MMIO regions, which implementation is provided in next patches. > > > > > > Signed-off-by: Leon Romanovsky > > > --- > > > drivers/vfio/pci/Kconfig | 20 ++++++++++++++++++++ > > > 1 file changed, 20 insertions(+) > > > > > > diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig > > > index 2b0172f54665..55ae888bf26a 100644 > > > --- a/drivers/vfio/pci/Kconfig > > > +++ b/drivers/vfio/pci/Kconfig > > > @@ -55,6 +55,26 @@ config VFIO_PCI_ZDEV_KVM > > > > > > To enable s390x KVM vfio-pci extensions, say Y. > > > > > > +config VFIO_PCI_DMABUF > > > + bool "VFIO PCI extensions for DMA-BUF" > > > + depends on VFIO_PCI_CORE > > > + depends on PCI_P2PDMA && DMA_SHARED_BUFFER > > > + default y > > > + help > > > + Enable support for VFIO PCI extensions that allow exporting > > > + device MMIO regions as DMA-BUFs for peer devices to access via > > > + peer-to-peer (P2P) DMA. > > > + > > > + This feature enables a VFIO-managed PCI device to export a portion > > > + of its MMIO BAR as a DMA-BUF file descriptor, which can be passed > > > + to other userspace drivers or kernel subsystems capable of > > > + initiating DMA to that region. > > > + > > > + Say Y here if you want to enable VFIO DMABUF-based MMIO export > > > + support for peer-to-peer DMA use cases. > > > + > > > + If unsure, say N. > > > + > > > source "drivers/vfio/pci/mlx5/Kconfig" > > > > > > source "drivers/vfio/pci/hisilicon/Kconfig" > > > > This is only necessary if we think there's a need to build a kernel with > > P2PDMA and VFIO_PCI, but not VFIO_PCI_DMABUF. Does that need really > > exist? > > It is used to filter build of vfio_pci_dmabuf.c - drivers/vfio/pci/Makefile: > vfio-pci-core-$(CONFIG_VFIO_PCI_DMABUF) += vfio_pci_dmabuf.o Maybe my question of whether it needs to exist at all is too broad. Does it need to be a user visible Kconfig option? Where do we see the need to preclude this feature from vfio-pci if the dependencies are enabled? > > I also find it unusual to create the Kconfig before adding the > > supporting code. Maybe this could be popped to the end or rolled into > > the last patch if we decided to keep it. Thanks, > > It is leftover from previous version, I can squash it, but first we need > to decide what to do with pcim_p2pdma_init() call, if it needs to be > guarded or not. As in the other thread, I think it would be cleaner in an IS_ENABLED branch. I'm tempted to suggest we filter out EOPNOTSUPP to allow it to be unconditional, but I understand your point with the list_head initialization. Thanks, Alex