qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	<linuxarm@huawei.com>
Cc: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>,
	<eric.auger@redhat.com>, <peter.maydell@linaro.org>,
	<jgg@nvidia.com>, <nicolinc@nvidia.com>, <ddutile@redhat.com>,
	<berrange@redhat.com>, <imammedo@redhat.com>,
	<nathanc@nvidia.com>, <mochs@nvidia.com>, <smostafa@google.com>,
	<gustavo.romero@linaro.org>, <wangzhou1@hisilicon.com>,
	<jiangkunkun@huawei.com>, <jonathan.cameron@huawei.com>,
	<zhangfei.gao@linaro.org>
Subject: Re: [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
Date: Mon, 23 Jun 2025 12:39:30 +0100	[thread overview]
Message-ID: <20250623123903.00007aff@huawei.com> (raw)
In-Reply-To: <20250623094230.76084-7-shameerali.kolothum.thodi@huawei.com>

On Mon, 23 Jun 2025 10:42:25 +0100
Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> wrote:

> Currently, pci_setup_iommu() registers IOMMU ops for a given PCIBus.
> However, when retrieving IOMMU ops for a device using
> pci_device_get_iommu_bus_devfn(), the function checks the parent_dev
> and fetches IOMMU ops from the parent device, even if the current
> bus does not have any associated IOMMU ops.
> 
> This behavior works for now because QEMU's IOMMU implementations are
> globally scoped, and host bridges rely on the bypass_iommu property
> to skip IOMMU translation when needed.
> 
> However, this model will break with the soon to be introduced
> arm-smmuv3 device, which allows users to associate the IOMMU
> with a specific PCIe root complex (e.g., the default pcie.0
> or a pxb-pcie root complex).
> 
> For example, consider the following setup with multiple root
> complexes:
> 
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.0 \
> ...
> -device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
> -device pcie-root-port,id=pcie.port1,bus=pcie.1 \
> -device virtio-net-pci,bus=pcie.port1
> 
> In Qemu, pxb-pcie acts as a special root complex whose parent is
> effectively the default root complex(pcie.0). Hence, though pcie.1
> has no associated SMMUv3 as per above, pci_device_get_iommu_bus_devfn()
> will incorrectly return the IOMMU ops from pcie.0 due to the fallback
> via parent_dev.
> 
> To fix this, introduce a new helper pci_setup_iommu_per_bus() that
> explicitly sets the new iommu_per_bus field in the PCIBus structure.

Maybe call out where this will later be called from?

Otherwise seems like a reasonable solution to me.

One trivial comment inline.

Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>


> Update pci_device_get_iommu_bus_devfn() to use this when determining
> the correct IOMMU ops, ensuring accurate behavior for per-bus IOMMUs.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> Please refer cover letter for more details on the issue that
> this is trying to fix.
> ---
>  hw/pci/pci.c             | 25 +++++++++++++++++++++++++
>  include/hw/pci/pci.h     |  2 ++
>  include/hw/pci/pci_bus.h |  1 +
>  3 files changed, 28 insertions(+)
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index c70b5ceeba..e1940c05d9 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c

> @@ -3169,6 +3182,18 @@ void pci_setup_iommu(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque)
>      bus->iommu_opaque = opaque;
>  }
>  
> +/*
> + * This is same as pci_setup_iommu() except it sets the iommu_per_bus
> + * to true indicating the iommu is specific to this bus and

Trivial: Odd line wrap.  At least not can go up a line.

> + * not applicable to any parent or child.
> + */
> +void pci_setup_iommu_per_bus(PCIBus *bus, const PCIIOMMUOps *ops,
> +                             void *opaque)
> +{
> +    pci_setup_iommu(bus, ops, opaque);
> +    bus->iommu_per_bus = true;



  reply	other threads:[~2025-06-23 11:40 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-23  9:42 [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
2025-06-23  9:42 ` [PATCH v5 01/11] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association Shameer Kolothum via
2025-06-23 11:32   ` Jonathan Cameron via
2025-06-27 11:52   ` Eric Auger
2025-06-30  7:01     ` Shameerali Kolothum Thodi via
2025-07-01  6:31       ` Eric Auger
2025-06-23  9:42 ` [PATCH v5 02/11] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build Shameer Kolothum via
2025-06-27 11:54   ` Eric Auger
2025-06-23  9:42 ` [PATCH v5 03/11] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices Shameer Kolothum via
2025-06-23  9:42 ` [PATCH v5 04/11] hw/arm/virt: Factor out common SMMUV3 dt bindings code Shameer Kolothum via
2025-06-23  9:42 ` [PATCH v5 05/11] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
2025-06-23 11:35   ` Jonathan Cameron via
2025-06-23  9:42 ` [PATCH v5 06/11] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval Shameer Kolothum via
2025-06-23 11:39   ` Jonathan Cameron via [this message]
2025-06-27 12:04   ` Eric Auger
2025-06-30  7:05     ` Shameerali Kolothum Thodi via
2025-06-23  9:42 ` [PATCH v5 07/11] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation Shameer Kolothum via
2025-06-23 11:46   ` Jonathan Cameron via
2025-06-27 12:05   ` Eric Auger
2025-06-23  9:42 ` [PATCH v5 08/11] qemu-options.hx: Document the arm-smmuv3 device Shameer Kolothum via
2025-06-23 11:47   ` Jonathan Cameron via
2025-06-27 12:08   ` Eric Auger
2025-06-23  9:42 ` [PATCH v5 09/11] bios-tables-test: Allow for smmuv3 test data Shameer Kolothum via
2025-06-23 11:49   ` Jonathan Cameron via
2025-06-27 12:14   ` Eric Auger
2025-06-23  9:42 ` [PATCH v5 10/11] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device Shameer Kolothum via
2025-06-23 11:57   ` Jonathan Cameron via
2025-06-27 12:34   ` Eric Auger
2025-06-30  7:08     ` Shameerali Kolothum Thodi via
2025-06-23  9:42 ` [PATCH v5 11/11] qtest/bios-tables-test: Update tables for smmuv3 tests Shameer Kolothum via
2025-06-23 12:00   ` Jonathan Cameron via
2025-06-27 12:36   ` Eric Auger
2025-06-30  7:11     ` Shameerali Kolothum Thodi via
2025-07-01  6:35       ` Eric Auger
2025-06-27 12:36 ` [PATCH v5 00/11] hw/arm/virt: Add support for user creatable SMMUv3 device Eric Auger
2025-06-30  7:12   ` Shameerali Kolothum Thodi via
2025-07-01  6:37     ` Eric Auger
2025-07-02  1:01 ` Nathan Chen
2025-07-02 15:08   ` Shameerali Kolothum Thodi via

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=20250623123903.00007aff@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=berrange@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=gustavo.romero@linaro.org \
    --cc=imammedo@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linuxarm@huawei.com \
    --cc=mochs@nvidia.com \
    --cc=nathanc@nvidia.com \
    --cc=nicolinc@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=smostafa@google.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=zhangfei.gao@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).