All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: Donald Dutile <ddutile@redhat.com>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	"jgg@nvidia.com" <jgg@nvidia.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"imammedo@redhat.com" <imammedo@redhat.com>,
	"nathanc@nvidia.com" <nathanc@nvidia.com>,
	"mochs@nvidia.com" <mochs@nvidia.com>,
	"smostafa@google.com" <smostafa@google.com>,
	"gustavo.romero@linaro.org" <gustavo.romero@linaro.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"marcel.apfelbaum@gmail.com" <marcel.apfelbaum@gmail.com>,
	Linuxarm <linuxarm@huawei.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>,
	jiangkunkun <jiangkunkun@huawei.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>
Subject: Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval
Date: Thu, 10 Jul 2025 15:56:55 -0700	[thread overview]
Message-ID: <aHBFNxLERkwcbL7d@Asurada-Nvidia> (raw)
In-Reply-To: <0ef59c7f11454954814501e41724f4fe@huawei.com>

On Thu, Jul 10, 2025 at 09:40:28PM +0000, Shameerali Kolothum Thodi wrote:
> > So, the logic is trying to avoid:
> >         "iommu_bus = parent_bus;"
> > for a case that parent_bus (pcie.0) having its own IOMMU.
> > 
> > But shouldn't it be just "if (parent_bus->iommu_per_bus)"?
> > 
> > Why does the current iommu_bus->iommu_per_bus has to be unset?
> 
> I think that !iommu_bus->iommu_per_bus check will be always true as 
> it enters the while loop only if !iommu_bus->iommu_ops case,
> 
> while (iommu_bus && !iommu_bus->iommu_ops && iommu_bus->parent_dev) {
> 
> }

Yea, that makses sense. "!iommu_bus->iommu_ops" should imply that
"iommu_bus->iommu_per_bus" is unset.

> > I think "iommu_bus = parent_bus" should be avoided too even if
> > the current iommu_bus has its own IOMMU, i.e. iommu_per_bus is
> > set?
> 
> Why? Not clear to me. It only enters the loop if the current iommu_bus
> doesn't have Iommu_ops set which in turn means iommu_per_bus is not set. 
> Isn't it?

Yea. I missed that condition. But what I said still stays correct:
if iommu_bus (pcie.1) has its own IOMMU, it shouldn't take the ops
from the parent_bus. The thing is that this logic is inside a while
condition that has already excluded such a case.

Thanks
Nicolin


  reply	other threads:[~2025-07-10 22:57 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08 15:40 [PATCH v7 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device Shameer Kolothum via
2025-07-08 15:40 ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 01/12] hw/arm/virt-acpi-build: Don't create ITS id mappings by default Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-10 13:59   ` Eric Auger
2025-07-10 15:20     ` Peter Maydell
2025-07-08 15:40 ` [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 20:57   ` Nicolin Chen
2025-07-09  8:08     ` Shameerali Kolothum Thodi via
2025-07-09  8:08       ` Shameerali Kolothum Thodi via
2025-07-09 23:54       ` Nicolin Chen
2025-07-10  7:27         ` Shameerali Kolothum Thodi via
2025-07-10  7:27           ` Shameerali Kolothum Thodi via
2025-07-10 17:02           ` Nicolin Chen
2025-07-10 17:07   ` Nicolin Chen
2025-07-08 15:40 ` [PATCH v7 03/12] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 04/12] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 05/12] hw/arm/virt: Factor out common SMMUV3 dt bindings code Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 06/12] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 21:26   ` Nicolin Chen
2025-07-09  8:20     ` Shameerali Kolothum Thodi via
2025-07-09  8:20       ` Shameerali Kolothum Thodi via
2025-07-10  0:06       ` Nicolin Chen
2025-07-10  7:37         ` Shameerali Kolothum Thodi via
2025-07-10  7:37           ` Shameerali Kolothum Thodi via
2025-07-10 15:59           ` Donald Dutile
2025-07-10 16:21             ` Shameerali Kolothum Thodi via
2025-07-10 16:21               ` Shameerali Kolothum Thodi via
2025-07-10 16:55               ` Nicolin Chen
2025-07-10 21:40                 ` Shameerali Kolothum Thodi via
2025-07-10 21:40                   ` Shameerali Kolothum Thodi via
2025-07-10 22:56                   ` Nicolin Chen [this message]
2025-07-10 16:58               ` Donald Dutile
2025-07-10 22:59   ` Nicolin Chen
2025-07-08 15:40 ` [PATCH v7 08/12] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 21:34   ` Nicolin Chen
2025-07-08 15:40 ` [PATCH v7 09/12] qemu-options.hx: Document the arm-smmuv3 device Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 10/12] bios-tables-test: Allow for smmuv3 test data Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 11/12] qtest/bios-tables-test: Add tests for legacy smmuv3 and smmuv3 device Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-08 15:40 ` [PATCH v7 12/12] qtest/bios-tables-test: Update tables for smmuv3 tests Shameer Kolothum via
2025-07-08 15:40   ` Shameer Kolothum via
2025-07-10 10:10 ` [PATCH v7 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device Shameerali Kolothum Thodi via
2025-07-10 10:10   ` Shameerali Kolothum Thodi via
2025-07-10 11:48   ` Peter Maydell
2025-07-10 23:04     ` Nicolin Chen

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=aHBFNxLERkwcbL7d@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --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=marcel.apfelbaum@gmail.com \
    --cc=mochs@nvidia.com \
    --cc=mst@redhat.com \
    --cc=nathanc@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@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 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.