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: "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>,
	"ddutile@redhat.com" <ddutile@redhat.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 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association
Date: Wed, 9 Jul 2025 16:54:17 -0700	[thread overview]
Message-ID: <aG8BKexuSHtSvySv@Asurada-Nvidia> (raw)
In-Reply-To: <92ca69322dea4a0b966ce9dd7eff0fb3@huawei.com>

On Wed, Jul 09, 2025 at 08:08:49AM +0000, Shameerali Kolothum Thodi wrote:
> > On Tue, Jul 08, 2025 at 04:40:45PM +0100, Shameer Kolothum wrote:
> > > @@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState
> > *dev, Error **errp)
> > >                                       g_free, g_free);
> > >      s->smmu_pcibus_by_busptr = g_hash_table_new(NULL, NULL);
> > 
> > Although this is not introduced by this patch, is there a
> > g_hash_table_remove() somewhere in the code?
> 
> g_hash_table_remove()  is to remove a key/value pair, isn't it?

Yes.

> Or you meant
> a corresponding free in case of failure here?

Yes. But I saw the other two g_hash_table_new_full calls were not
reverted in the exit path either. Then I saw smmu_base_reset_exit
does the clean up of those two but not this smmu_pcibus_by_busptr.

> It's a realize() fn and errp is set
> if something goes wrong and QEMU will exit. Not sure we need an explicit
> free here.
>  
> > > +    /*
> > > +     * We only allow default PCIe Root Complex(pcie.0) or pxb-pcie based
> > extra
> > > +     * root complexes to be associated with SMMU.
> > > +     */
> > > +    if (pci_bus_is_express(pci_bus) && pci_bus_is_root(pci_bus) &&
> > > +        object_dynamic_cast(OBJECT(pci_bus)->parent,
> > TYPE_PCI_HOST_BRIDGE)) {
> > > +        /*
> > > +         * For pxb-pcie, parent_dev will be set. Make sure it is
> > > +         * pxb-pcie indeed.
> > > +         */
> > > +        if (pci_bus->parent_dev) {
> > > +            if (!object_dynamic_cast(OBJECT(pci_bus), TYPE_PXB_PCIE_BUS)) {
> > 
> > The pci_bus_is_express(pci_bus) at the top is equivalent to:
> > 	object_dynamic_cast(OBJECT(pci_bus), TYPE_PCIE_BUS)
> > Then here it is doing:
> > 	object_dynamic_cast(OBJECT(pci_bus), TYPE_PXB_PCIE_BUS)
> 
> Yes.

Hmm?

We have these two types defined as two different strings, right?

#define TYPE_PCIE_BUS "PCIE"
#define TYPE_PXB_PCIE_BUS "pxb-pcie-bus"

So the first test is to make sure pci_bus string is "PCIE",
then the second one testing the same pci_bus string will
never be true?

> > So, this checks the same pci_bus but expects two different types?
> 
> In QEMU,  we can have three types of PCIe root complexes to be specified for
> virt machine. 
> 
> 1. default pcie.0 (TYPE_GPEX_HOST --> TYPE_PCIE_HOST_BRIDGE --> TYPE_PCI_HOST_BRIDGE)
> 2. pxb-pcie (TYPE_PXB_HOST  -->TYPE_PCI_HOST_BRIDGE)
> 2. pxb-cxl (TYPE_PXB_CXL_HOST  --> TYPE_PCI_HOST_BRIDGE)
> 
> The above first check is to see whether the bus is  PCIE && root bus && parent 
> of type TYPE_PCI_HOST_BRIDGE. This will identify all the above three cases.
> 
> Both pxb-pcie and pxb-cxl are special extra root complexes based on PCI
> expansion bridges and has a parent_dev set(both has pcie.0 has parent bus).
> 
> Hence we check to see parent_dev is set and make sure it is indeed 
> TYPE_PXB_PCIE_BUS to avoid attaching to pxb-cxl. 

I see. That's clear now. I think it'd help by writing:
		/*
		 * While pcie.0 doesn't set the parent_dev, either pxb-pcie or
		 * pxb-cxl does. Re-test the type to make sure it is pxb-pcie.
		 */

Thanks
Nicolin


  reply	other threads:[~2025-07-09 23:55 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 [this message]
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
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=aG8BKexuSHtSvySv@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.