All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: <liujie5@linkdatatechnology.com>
Cc: <stephen@networkplumber.org>, <dev@dpdk.org>,
	liufeng1 <liufeng1@sugon.com>
Subject: Re: [PATCH v1 1/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag
Date: Mon, 12 Oct 2026 08:53:41 +0100	[thread overview]
Message-ID: <asySBXhKMzigqIDW@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20261010092525.2025485-2-liujie5@linkdatatechnology.com>

On Sat, Oct 10, 2026 at 05:25:25PM +0800, liujie5@linkdatatechnology.com wrote:
> From: liufeng1 <liufeng1@sugon.com>
> 
> Add a new PCI driver flag, RTE_PCI_DRV_NEED_IOVA_AS_PA, that allows a
> driver to tell the PCI bus layer it cannot work with IOVA as VA and
> must use IOVA as PA.
> 
> The existing RTE_PCI_DRV_NEED_IOVA_AS_VA flag already provides the
> opposite requirement. Some PCI devices, however, are managed by a
> kernel driver that uses an identity-mapped IOMMU domain (e.g. when the
> 		kernel is booted with iommu=pt). The user-space PMD for such devices
> must use IOVA as PA, because the DMA addresses programmed by DPDK must
> match the identity mapping programmed by the kernel driver.
> 
> Without this flag, a PCI driver bound to a non-VFIO/UIO kernel driver
> has no way to force IOVA as PA. pci_device_iova_mode() returns
> RTE_IOVA_DC for those devices, and rte_eal_init() then sees an enabled
> IOMMU and selects RTE_IOVA_VA, which breaks identity-domain PMDs and
> forces users to pass --iova-mode=pa on the command line.
> 
> When RTE_PCI_DRV_NEED_IOVA_AS_PA is set, pci_device_iova_mode()
> returns RTE_IOVA_PA for the device. The requirement is propagated
> through rte_pci_get_iommu_class() to rte_bus_get_iommu_class(), so
> rte_eal_init() selects IOVA as PA automatically.
> 
> This is a generic mechanism: any PCI driver whose underlying kernel
> driver uses an identity IOMMU domain can set the flag.
> 
> Signed-off-by: Jie Liu <liujie5@linkdatatechnology.com>
> ---
>  drivers/bus/pci/bus_pci_driver.h | 2 ++
>  drivers/bus/pci/linux/pci.c      | 4 ++++
>  drivers/bus/pci/pci_common.c     | 3 +--
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bus/pci/bus_pci_driver.h b/drivers/bus/pci/bus_pci_driver.h
> index c04ebddf59..5d5efbbb3e 100644
> --- a/drivers/bus/pci/bus_pci_driver.h
> +++ b/drivers/bus/pci/bus_pci_driver.h
> @@ -140,6 +140,8 @@ struct rte_pci_driver {
>  #define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
>  /** Device driver needs IOVA as VA and cannot work with IOVA as PA */
>  #define RTE_PCI_DRV_NEED_IOVA_AS_VA 0x0040
> +/** Device driver needs IOVA as PA and cannot work with IOVA as VA */
> +#define RTE_PCI_DRV_NEED_IOVA_AS_PA 0x0080
>  
>  /**
>   * Register a PCI driver.
> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c
> index bcf0a409da..bf7125e214 100644
> --- a/drivers/bus/pci/linux/pci.c
> +++ b/drivers/bus/pci/linux/pci.c
> @@ -609,6 +609,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
>  			iova_mode = RTE_IOVA_PA;
>  		else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
>  			iova_mode = RTE_IOVA_VA;
> +		else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
> +			iova_mode = RTE_IOVA_PA;
>  		break;
>  	}
>  
> @@ -620,6 +622,8 @@ pci_device_iova_mode(const struct rte_pci_driver *pdrv,
>  	default:
>  		if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_VA) != 0)
>  			iova_mode = RTE_IOVA_VA;
> +		else if ((pdrv->drv_flags & RTE_PCI_DRV_NEED_IOVA_AS_PA) != 0)
> +			iova_mode = RTE_IOVA_PA;
>  		break;
>  	}
>  	return iova_mode;

Do we need a sanity check somewhere that we don't have two drivers with
conflicting flags set i.e. one NEED_IOVA_AS_VA and one NEED_IOVA_AS_PA? It
should never happen, I imagine, but things that should never happen have
this annoying habit of sometimes happening! :-)

/Bruce


      reply	other threads:[~2026-10-12  7:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10  9:25 [PATCH v1 0/1] bus/pci: add RTE_PCI_DRV_NEED_IOVA_AS_PA flag liujie5
2026-10-10  9:25 ` [PATCH v1 1/1] " liujie5
2026-10-12  7:53   ` Bruce Richardson [this message]

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=asySBXhKMzigqIDW@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=liufeng1@sugon.com \
    --cc=liujie5@linkdatatechnology.com \
    --cc=stephen@networkplumber.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.