Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Alex Williamson <alex@shazbot.org>
To: Zhiping Zhang <zhipingz@meta.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	Michael Guralnik <michaelgur@nvidia.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Christian Konig <christian.koenig@amd.com>,
	Bjorn Helgaas <bhelgaas@google.com>, <kvm@vger.kernel.org>,
	<linux-rdma@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	alex@shazbot.org
Subject: Re: [PATCH v10 3/4] vfio/pci: implement get_pci_tph and DMA_BUF_TPH feature
Date: Wed, 1 Jul 2026 12:07:00 -0600	[thread overview]
Message-ID: <20260701120700.58bcafa1@shazbot.org> (raw)
In-Reply-To: <20260630224328.3218796-4-zhipingz@meta.com>

On Tue, 30 Jun 2026 15:42:25 -0700
Zhiping Zhang <zhipingz@meta.com> wrote:

> Implement dma-buf get_pci_tph for vfio-pci exported dma-bufs and add
> VFIO_DEVICE_FEATURE_DMA_BUF_TPH so userspace can publish TPH metadata
> for a VFIO-owned device.
> 
> 8-bit ST and 16-bit Extended ST are distinct PCIe TPH namespaces; the
> uAPI carries both with explicit validity flags, and get_pci_tph()
> returns the value matching the importer's requested namespace or
> -EOPNOTSUPP.
> 
> Publish and read the TPH descriptor under dmabuf->resv, matching the
> locking used for other importer-visible dma-buf state. The SET ioctl
> takes dma_resv_lock_interruptible(), while the callback runs under
> DMA-buf's asserted resv lock.
> 
> Reject requests the device cannot consume as a completer:
> pcie_tph_completer_type() must report at least
> PCI_EXP_DEVCAP2_TPH_COMP_TPH_ONLY, and Extended ST requires
> PCI_EXP_DEVCAP2_TPH_COMP_EXT_TPH. Make PROBE follow the same hardware
> gate so the feature only probes as supported when the device can really
> consume it.
> 
> Signed-off-by: Zhiping Zhang <zhipingz@meta.com>
> ---
>  drivers/vfio/pci/vfio_pci_core.c   |  3 +
>  drivers/vfio/pci/vfio_pci_dmabuf.c | 99 +++++++++++++++++++++++++++++-
>  drivers/vfio/pci/vfio_pci_priv.h   | 12 ++++
>  include/uapi/linux/vfio.h          | 43 +++++++++++++
>  4 files changed, 155 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index a28f1e99362c..c7d6902bc61b 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -1572,6 +1572,9 @@ int vfio_pci_core_ioctl_feature(struct vfio_device *device, u32 flags,
>  		return vfio_pci_core_feature_token(vdev, flags, arg, argsz);
>  	case VFIO_DEVICE_FEATURE_DMA_BUF:
>  		return vfio_pci_core_feature_dma_buf(vdev, flags, arg, argsz);
> +	case VFIO_DEVICE_FEATURE_DMA_BUF_TPH:
> +		return vfio_pci_core_feature_dma_buf_tph(vdev, flags, arg,
> +							 argsz);
>  	default:
>  		return -ENOTTY;
>  	}
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index c16f460c01d6..8de72f9e7502 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> @@ -3,6 +3,7 @@
>   */
>  #include <linux/dma-buf-mapping.h>
>  #include <linux/pci-p2pdma.h>
> +#include <linux/pci-tph.h>
>  #include <linux/dma-resv.h>
>  
>  #include "vfio_pci_priv.h"
> @@ -19,7 +20,14 @@ struct vfio_pci_dma_buf {
>  	u32 nr_ranges;
>  	struct kref kref;
>  	struct completion comp;
> -	u8 revoked : 1;
> +
> +	/* Protected by dmabuf->resv. */
> +	u16 tph_st_ext;
> +	u8 tph_st;
> +	bool revoked;
> +	u8 tph_st_valid:1;
> +	u8 tph_st_ext_valid:1;
> +	u8 tph_ph:2;

Since it seems there will be a v11, note again the comment made here on
v9:

On Tue, 23 Jun 2026 22:24:54 -0700
Zhiping Zhang <zhipingz@meta.com> wrote:
> On Tue, Jun 23, 2026 at 11:17 AM Alex Williamson <alex@shazbot.org> wrote:
> >
> > Nit, it would be more accurate to say:
> >
> >         /*
> >          * Updates protected by dmabuf->resv, @revoked additionally
> >          * protected by memory_lock.
> >          */
> >
> > revoked also has an unprotected read, but it's previously existing and
> > benign, and likely just needs a READ_ONCE() annotation.
> >  
> 
> Agreed, I'll update the comment and add READ_ONCE() as well.

The READ_ONCE was added, but the comment remains as in v9.  The
READ_ONCE rationale should be described in the commit log too.  Thanks,

Alex

  parent reply	other threads:[~2026-07-01 18:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 22:42 [PATCH v10 0/4] vfio/dma-buf: add TPH support for peer-to-peer access Zhiping Zhang
2026-06-30 22:42 ` [PATCH v10 1/4] PCI/TPH: Add requester/completer type helpers Zhiping Zhang
2026-06-30 23:07   ` sashiko-bot
2026-06-30 22:42 ` [PATCH v10 2/4] dma-buf: add optional get_pci_tph() callback Zhiping Zhang
2026-06-30 23:01   ` sashiko-bot
2026-07-01  8:25   ` Christian König
2026-07-01 17:53     ` Zhiping Zhang
2026-07-02  7:06       ` Christian König
2026-06-30 22:42 ` [PATCH v10 3/4] vfio/pci: implement get_pci_tph and DMA_BUF_TPH feature Zhiping Zhang
2026-06-30 23:08   ` sashiko-bot
2026-07-01 18:07   ` Alex Williamson [this message]
2026-07-01 21:07     ` Zhiping Zhang
2026-06-30 22:42 ` [PATCH v10 4/4] RDMA/mlx5: get tph for p2p access when registering dma-buf mr Zhiping Zhang
2026-06-30 23:11   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260701120700.58bcafa1@shazbot.org \
    --to=alex@shazbot.org \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michaelgur@nvidia.com \
    --cc=sumit.semwal@linaro.org \
    --cc=zhipingz@meta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox