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 09:55:32 -0700 [thread overview]
Message-ID: <aG/whNETIoHGnI5O@Asurada-Nvidia> (raw)
In-Reply-To: <f3bfc4cdb0ca47da8f3e4bc38b58d3b6@huawei.com>
On Thu, Jul 10, 2025 at 04:21:41PM +0000, Shameerali Kolothum Thodi wrote:
> > >> On Wed, Jul 09, 2025 at 08:20:35AM +0000, Shameerali Kolothum Thodi
> > >> wrote:
> > >>>> On Tue, Jul 08, 2025 at 04:40:50PM +0100, Shameer Kolothum wrote:
> > >>>>> @@ -2909,6 +2909,19 @@ static void
> > >>>> pci_device_get_iommu_bus_devfn(PCIDevice *dev,
> > >>>>> }
> > >>>>> }
> > >>>>>
> > >>>>> + /*
> > >>>>> + * When multiple PCI Express Root Buses are defined using
> > >>>>> + pxb-
> > >>>> pcie,
> > >>>>> + * the IOMMU configuration may be specific to each root bus.
> > >>>> However,
> > >>>>> + * pxb-pcie acts as a special root complex whose parent
> > >>>>> + is
> > >>>> effectively
> > >>>>> + * the default root complex(pcie.0). Ensure that we retrieve the
> > >>>>> + * correct IOMMU ops(if any) in such cases.
> > >>>>> + */
> > >>>>> + if (pci_bus_is_express(iommu_bus) &&
> > >>>> pci_bus_is_root(iommu_bus)) {
> > >>>>> + if (!iommu_bus->iommu_per_bus && parent_bus-
> > >>>>> iommu_per_bus) {
> > >>>>> + break;
> > >>>>
> > >>>> Mind elaborating why the current bus must unset iommu_per_bus
> > >> while
> > >>>> its parent sets iommu_per_bus?
> > >>>>
> > >>>> My understanding is that for a pxb-pcie we should set
> > iommu_per_bus
> > >>>> but for its parent (the default root complex) we should unset its
> > >>>> iommu_per_bus?
> > >>>
> > >>> Well, for new arm-smmuv3 dev you need an associated pcie root
> > >>> complex. Either the default pcie.0 or a pxb-pcie one. And as I
> > >>> mentioned in my reply to the other thread(patch #2) and commit log
> > >> here,
> > >>> the pxb-pcie is special extra root complex in Qemu which has pcie.0
> > >>> has parent bus.
> > >>>
> > >>> The above pci_device_get_iommu_bus_devfn() at present, iterate over
> > >> the
> > >>> parent_dev if it is set and returns the parent_bus IOMMU ops even if
> > >>> the associated pxb-pcie bus doesn't have any IOMMU. This creates
> > >>> problem for a case that is described here in the cover letter here,
> > >>> https://lore.kernel.org/qemu-devel/20250708154055.101012-1-
> > >> shameerali.kolothum.thodi@huawei.com/
> > >>>
> > >>> (Please see "Major changes from v4:" section)
> > >>>
> > >>> To address that issue, this patch introduces an new helper function
> > >>> to
> > >> specify that
> > >>> the IOMMU ops are specific to the associated root
> > >> complex(iommu_per_bus) and
> > >>> use that to return the correct IOMMU ops.
> > >>>
> > >>> Hope with that context it is clear now.
> > >>
> > >> Hmm, I was not questioning the context, I get what the patch is
> > >> supposed to do.
> > >>
> > >> I was asking the logic that is unclear to me why it breaks when:
> > >> !pxb-pcie->iommu_per_bus && pcie.0->iommu_per_bus
> > >>
> > >> Or in which case pcie.0 would be set to iommu_per_bus=true?
> > >
> > > Yes. Consider the example I gave in cover letter,
> > >
> > > -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.1 \ -device
> > > virtio-net-pci,bus=pcie.0,netdev=net0,id=virtionet.0 \ -device
> > > pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \ -device
> > > arm-smmuv3,primary-bus=pcie.1,id=smmuv3.2 \ -device
> > > pcie-root-port,id=pcie.port1,chassis=2,bus=pcie.1 \ -device
> > > virtio-net-pci,bus=pcie.port1,netdev=net1,id=virtionet.1
> > >
> > > pcie.0 is behind new SMMUv3 dev(smmuv3.1) and has iommu_per_bus
> > set.
> > > pcie.1 has no SMMv3U and iommu_per_bus is not set for it.
> > pcie.1 doesn't? then what is this line saying/meaning?:
> > -device arm-smmuv3,primary-bus=pcie.1,id=smmuv3.2 \
> >
> > I read that as an smmuv3 attached to pcie.1, with an id of smmuv3.2; just
> > as I read this config:
> > -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.1 \ as an smmuv3
> > attached to pcie.0 iwth id smmuv3.1
>
> Oops..I forgot to delete that from the config:
> This is what I meant,
>
> -device arm-smmuv3,primary-bus=pcie.0,id=smmuv3.1 \
> -device virtio-net-pci,bus=pcie.0,netdev=net0,id=virtionet.0 \
> -device pxb-pcie,id=pcie.1,bus_nr=8,bus=pcie.0 \
> -device pcie-root-port,id=pcie.port1,chassis=2,bus=pcie.1 \
> -device virtio-net-pci,bus=pcie.port1,netdev=net1,id=virtionet.1 \
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 "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?
Thanks
Nicolin
next prev parent reply other threads:[~2025-07-10 17:25 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 [this message]
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
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=aG/whNETIoHGnI5O@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.