All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: Jonathan Cameron <jonathan.cameron@huawei.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>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	"ddutile@redhat.com" <ddutile@redhat.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"clg@redhat.com" <clg@redhat.com>,
	"alex@shazbot.org" <alex@shazbot.org>,
	Nathan Chen <nathanc@nvidia.com>, Matt Ochs <mochs@nvidia.com>,
	"smostafa@google.com" <smostafa@google.com>,
	"wangzhou1@hisilicon.com" <wangzhou1@hisilicon.com>,
	"jiangkunkun@huawei.com" <jiangkunkun@huawei.com>,
	"zhangfei.gao@linaro.org" <zhangfei.gao@linaro.org>,
	"zhenzhong.duan@intel.com" <zhenzhong.duan@intel.com>,
	"yi.l.liu@intel.com" <yi.l.liu@intel.com>,
	Krishnakant Jaju <kjaju@nvidia.com>
Subject: Re: [PATCH v7 33/36] hw/pci: Add helper to insert PCIe extended capability at a fixed offset
Date: Wed, 14 Jan 2026 07:35:01 -0500	[thread overview]
Message-ID: <20260114073338-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CH3PR12MB7548C1DABCCCB8CB332B59A0AB8FA@CH3PR12MB7548.namprd12.prod.outlook.com>

On Wed, Jan 14, 2026 at 12:26:29PM +0000, Shameer Kolothum wrote:
> 
> 
> > -----Original Message-----
> > From: Jonathan Cameron <jonathan.cameron@huawei.com>
> > Sent: 14 January 2026 11:46
> > To: Shameer Kolothum <skolothumtho@nvidia.com>
> > Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org;
> > eric.auger@redhat.com; peter.maydell@linaro.org; Jason Gunthorpe
> > <jgg@nvidia.com>; Nicolin Chen <nicolinc@nvidia.com>; ddutile@redhat.com;
> > berrange@redhat.com; clg@redhat.com; alex@shazbot.org; Nathan Chen
> > <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>;
> > smostafa@google.com; wangzhou1@hisilicon.com;
> > jiangkunkun@huawei.com; zhangfei.gao@linaro.org;
> > zhenzhong.duan@intel.com; yi.l.liu@intel.com; Krishnakant Jaju
> > <kjaju@nvidia.com>; Michael S . Tsirkin <mst@redhat.com>
> > Subject: Re: [PATCH v7 33/36] hw/pci: Add helper to insert PCIe extended
> > capability at a fixed offset
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Sun, 11 Jan 2026 19:53:19 +0000
> > Shameer Kolothum <skolothumtho@nvidia.com> wrote:
> > 
> > > Add pcie_insert_capability(), a helper to insert a PCIe extended
> > > capability into an existing extended capability list at a
> > > caller-specified offset.
> > >
> > > Unlike pcie_add_capability(), which always appends a capability to the
> > > end of the list, this helper preserves the existing list ordering while
> > > allowing insertion at an arbitrary offset.
> > >
> > > The helper only validates that the insertion does not overwrite an
> > > existing PCIe extended capability header, since corrupting a header
> > > would break the extended capability linked list. Validation of overlaps
> > > with other configuration space registers or capability-specific
> > > register blocks is left to the caller.
> > >
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> > Hi Shameer.
> 
> Happy new year!
> 
> > 
> > Random musings inline... Maybe I'm just failing in my spec grep skills.
> > 
> > > ---
> > >  hw/pci/pcie.c         | 58
> > +++++++++++++++++++++++++++++++++++++++++++
> > >  include/hw/pci/pcie.h |  2 ++
> > >  2 files changed, 60 insertions(+)
> > >
> > > diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
> > > index b302de6419..8568a062a5 100644
> > > --- a/hw/pci/pcie.c
> > > +++ b/hw/pci/pcie.c
> > > @@ -1050,6 +1050,64 @@ static void pcie_ext_cap_set_next(PCIDevice
> > *dev, uint16_t pos, uint16_t next)
> > >      pci_set_long(dev->config + pos, header);
> > >  }
> > >
> > > +/*
> > > + * Insert a PCIe extended capability at a given offset.
> > > + *
> > > + * This helper only validates that the insertion does not overwrite an
> > > + * existing PCIe extended capability header, as corrupting a header would
> > > + * break the extended capability linked list.
> > > + *
> > > + * The caller must ensure that (offset, size) does not overlap with other
> > > + * registers or capability-specific register blocks. Overlaps with
> > > + * capability-specific registers are not checked and are considered a
> > > + * user-controlled override.
> > > + */
> > > +bool pcie_insert_capability(PCIDevice *dev, uint16_t cap_id, uint8_t
> > cap_ver,
> > > +                            uint16_t offset, uint16_t size)
> > > +{
> > > +    uint16_t prev = 0, next = 0;
> > > +    uint16_t cur = pci_get_word(dev->config + PCI_CONFIG_SPACE_SIZE);
> > > +
> > > +    /* Walk the ext cap list to find insertion point */
> > > +    while (cur) {
> > > +        uint32_t hdr = pci_get_long(dev->config + cur);
> > > +        next = PCI_EXT_CAP_NEXT(hdr);
> > > +
> > > +        /* Check we are not overwriting any existing CAP header area */
> > > +        if (offset >= cur && offset < cur + PCI_EXT_CAP_ALIGN) {
> > > +            return false;
> > > +        }
> > > +
> > > +        prev = cur;
> > > +        cur = next;
> > > +        if (next == 0 || next > offset) {
> > 
> > So this (sort of) relies on a thing I've never been able to find a clear
> > statement of in the PCIe spec.  Does Next Capability Offset have to be
> > larger than the offset of the current record?  I.e. Can we have
> > backwards pointers?
> 
> That’s right. I also couldn’t find a place in the spec that explicitly
> says the list must be forward only. A device doing a backward walk
> would be pretty odd, hopefully nothing like that exists in the wild.

Yes, there's no reason not to have such pointers, with either
PCIe or classical PCI capability.


> > Meh, I think this is fine, it just came up before and I couldn't find
> > a reference to prove it!
> > 
> > More importantly, if it isn't a requirement and a rare device turns up
> > that has a backwards pointer, that just means there isn't a 'right'
> > point in the list to put this at, so any random choice is fine and
> > the next == 0 condition means we always fine an option.
> 
> Yes. 
> 
> > 
> > > +            break;
> > > +        }
> > > +    }
> > > +
> > > +   /* Make sure, next CAP header area is not over written either */
> > 
> > Looks like one space too few.
> > 
> > > +    if (next && (offset + size) >= next) {
> > > +        return false;
> > > +    }
> > > +
> > > +    /* Insert new cap */
> > > +    pci_set_long(dev->config + offset,
> > > +                 PCI_EXT_CAP(cap_id, cap_ver, cur));
> > > +    if (prev) {
> > > +        pcie_ext_cap_set_next(dev, prev, offset);
> > > +    } else {
> > > +        /* Insert at head (0x100) */
> > 
> > Comment is a little confusing as you aren't inserting the new capability
> > there.  What I think this is actually doing is
> > 
> > /*
> >  * Insert a Null Extended Capability (7.9.28 in the PCI 6.2 spec)
> >  * at head when there are no extended capabilities and use that to
> >  * point to the inserted capability at offset.
> >  */
> 
> Sure. However, Zhangfei has reported a crash with this and I have
> reworked the logic a bit to cover few corner cases. Based on his
> tests I will update this.
> 
> Thanks,
> Shameer
> 
> > > +        pci_set_word(dev->config + PCI_CONFIG_SPACE_SIZE, offset);
> > > +    }
> > > +
> > > +    /* Make capability read-only by default */
> > > +    memset(dev->wmask + offset, 0, size);
> > > +    memset(dev->w1cmask + offset, 0, size);
> > > +    /* Check capability by default */
> > > +    memset(dev->cmask + offset, 0xFF, size);
> > > +    return true;
> > > +}
> > 
> 



  reply	other threads:[~2026-01-14 12:35 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-11 19:52 [PATCH v7 00/36] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 01/36] backends/iommufd: Introduce iommufd_backend_alloc_vdev Shameer Kolothum
2026-01-12 11:45   ` Cédric Le Goater
2026-01-12 14:04     ` Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 02/36] hw/arm/smmu-common: Factor out common helper functions and export Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 03/36] hw/arm/smmu-common: Make iommu ops part of SMMUState Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 04/36] hw/arm/smmuv3-accel: Introduce smmuv3 accel device Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 05/36] hw/arm/smmuv3-accel: Initialize shared system address space Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 06/36] hw/pci/pci: Move pci_init_bus_master() after adding device to bus Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 07/36] hw/pci/pci: Add optional supports_address_space() callback Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 08/36] hw/pci-bridge/pci_expander_bridge: Move TYPE_PXB_PCIE_DEV to header Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 09/36] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 10/36] hw/arm/smmuv3: Implement get_viommu_cap() callback Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 11/36] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 12/36] hw/arm/smmuv3: propagate smmuv3_cmdq_consume() errors to caller Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 13/36] hw/arm/smmuv3-accel: Add nested vSTE install/uninstall support Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 14/36] hw/arm/smmuv3-accel: Install SMMUv3 GBPA based hwpt Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 15/36] hw/pci/pci: Introduce a callback to retrieve the MSI doorbell GPA directly Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 16/36] hw/arm/smmuv3-accel: Implement get_msi_direct_gpa callback Shameer Kolothum
2026-01-19 13:59   ` Eric Auger
2026-01-11 19:53 ` [PATCH v7 17/36] hw/arm/virt: Set msi-gpa property Shameer Kolothum
2026-01-11 21:43   ` Mohamed Mediouni
2026-01-12  9:45     ` Shameer Kolothum
2026-01-12 10:17       ` Mohamed Mediouni
2026-01-12 15:01         ` Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 18/36] hw/arm/smmuv3-accel: Add support to issue invalidation cmd to host Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 19/36] hw/arm/smmuv3: Initialize ID registers early during realize() Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 20/36] hw/arm/smmuv3-accel: Get host SMMUv3 hw info and validate Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 21/36] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5 Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 22/36] hw/arm/virt: Set PCI preserve_config for accel SMMUv3 Shameer Kolothum
2026-01-14 11:13   ` Jonathan Cameron via
2026-01-14 11:13     ` Jonathan Cameron via qemu development
2026-01-11 19:53 ` [PATCH v7 23/36] tests/qtest/bios-tables-test: Prepare for IORT revison upgrade Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 24/36] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 25/36] tests/qtest/bios-tables-test: Update IORT blobs after revision upgrade Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 26/36] hw/arm/smmuv3: Block migration when accel is enabled Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 27/36] hw/arm/smmuv3: Add accel property for SMMUv3 device Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 28/36] hw/arm/smmuv3-accel: Add a property to specify RIL support Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 29/36] hw/arm/smmuv3-accel: Add support for ATS Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 30/36] hw/arm/smmuv3-accel: Add property to specify OAS bits Shameer Kolothum
2026-01-14 11:19   ` Jonathan Cameron via
2026-01-14 11:19     ` Jonathan Cameron via qemu development
2026-01-11 19:53 ` [PATCH v7 31/36] backends/iommufd: Retrieve PASID width from iommufd_backend_get_device_info() Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 32/36] backends/iommufd: Add get_pasid_info() callback Shameer Kolothum
2026-01-14 11:23   ` Jonathan Cameron via
2026-01-14 11:23     ` Jonathan Cameron via qemu development
2026-01-19 14:06   ` Eric Auger
2026-01-11 19:53 ` [PATCH v7 33/36] hw/pci: Add helper to insert PCIe extended capability at a fixed offset Shameer Kolothum
2026-01-14  4:18   ` Zhangfei Gao
2026-01-14 10:36     ` Shameer Kolothum
2026-01-15  2:34       ` Zhangfei Gao
2026-01-19 16:01       ` Eric Auger
2026-01-19 16:03         ` Shameer Kolothum
2026-01-14 11:45   ` Jonathan Cameron via
2026-01-14 11:45     ` Jonathan Cameron via qemu development
2026-01-14 12:26     ` Shameer Kolothum
2026-01-14 12:35       ` Michael S. Tsirkin [this message]
2026-01-15 11:38         ` Jonathan Cameron via
2026-01-15 11:38           ` Jonathan Cameron via qemu development
2026-01-11 19:53 ` [PATCH v7 34/36] hw/pci: Factor out common PASID capability initialization Shameer Kolothum
2026-01-14 11:46   ` Jonathan Cameron via
2026-01-14 11:46     ` Jonathan Cameron via qemu development
2026-01-19 14:12   ` Eric Auger
2026-01-11 19:53 ` [PATCH v7 35/36] hw/vfio/pci: Synthesize PASID capability for vfio-pci devices Shameer Kolothum
2026-01-12  2:38   ` Duan, Zhenzhong
2026-01-14 11:51   ` Jonathan Cameron via
2026-01-14 11:51     ` Jonathan Cameron via qemu development
2026-01-19 16:16   ` Eric Auger
2026-01-19 17:22     ` Shameer Kolothum
2026-01-19 19:07       ` Cédric Le Goater
2026-01-11 19:53 ` [PATCH v7 36/36] hw/arm/smmuv3-accel: Make SubstreamID support configurable Shameer Kolothum
2026-01-19  8:17 ` [PATCH v7 00/36] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Zhangfei Gao
2026-01-19  8:36   ` Shameer Kolothum
2026-01-19 14:20 ` Michael S. Tsirkin
2026-01-19 16:57 ` Eric Auger

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=20260114073338-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alex@shazbot.org \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kjaju@nvidia.com \
    --cc=mochs@nvidia.com \
    --cc=nathanc@nvidia.com \
    --cc=nicolinc@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=skolothumtho@nvidia.com \
    --cc=smostafa@google.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=yi.l.liu@intel.com \
    --cc=zhangfei.gao@linaro.org \
    --cc=zhenzhong.duan@intel.com \
    /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.