From: Jason Gunthorpe <jgg@ziepe.ca>
To: Shyam Saini <shyamsaini@linux.microsoft.com>
Cc: Will Deacon <will@kernel.org>,
thierry.reding@gmail.com, robin.murphy@arm.com, robh@kernel.org,
joro@8bytes.org, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
virtualization@lists.linux.dev, jacob.pan@linux.microsoft.com,
eric.auger@redhat.com, code@tyhicks.com,
eahariha@linux.microsoft.com, vijayb@linux.microsoft.com,
bboscaccy@linux.microsoft.com, saravanak@google.com,
krzk+dt@kernel.org, conor+dt@kernel.org, lizhi.hou@amd.com,
clement.leger@bootlin.com
Subject: Re: [PATCH v4 3/4] arm-smmu: select suitable MSI IOVA
Date: Tue, 23 Sep 2025 13:19:12 -0300 [thread overview]
Message-ID: <20250923161912.GB2547959@ziepe.ca> (raw)
In-Reply-To: <20250923155647.GA22010@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Tue, Sep 23, 2025 at 08:56:47AM -0700, Shyam Saini wrote:
> Hi Jason, Will,
>
> On 19 Sep 2025 09:08, Jason Gunthorpe wrote:
> > On Fri, Sep 19, 2025 at 08:33:23AM +0100, Will Deacon wrote:
> > > pieces and will need to work on the userspace side. It's not like
> > > MSI_IOVA2 is magically going to work (and I bet it won't be tested).
> >
> > It could, if someone checks the default memory map a second constant
> > could be selected that works.
> >
> > > > Nicolin has some patches on the iommufd side to let userspace select
> > > > the MSI address instead, but they are not done yet.
> > >
> > > Maybe we should just wait for that? Carrying a temporary hack with ABI
> > > implications to support broken hardware isn't particularly compelling
> > > to me.
> >
> > This patch would still be needed for kernel users.
> >
> > Arguably the kernel users should just be using the iova allocator from
> > dma-iommu.c. This whole hard coded constant/sneaky uapi is just a hack
> > to make vfio work..
> >
> > So maybe if the single constant doesn't work we could set some
> > indication that the caller must allocate the MSI iova, the kernel can
> > use the dma-iommu allocator and VFIO can just refuse to use the device
> > for now.
>
> So, are we settling on having two predefined MSI IOVA base constants,
> and if both of those conflict with reserved regions on a given platform,
> falling back to dynamic allocation via the IOVA allocator? Just checking
> if that's the consensus we're reaching.
I think Will is arguing against introducing a new constant..
Yesterday I was looking at the SW_MSI code again.. What specific
problem is it you have?
It looks to me like dma-iommu.c is already allocating MSI addresses
using its built in IOVA allocator. So if your DT is marking that space
reserved then it should Just Work right now as dma-iommu.c already
processes the reserved ranges and will allocate MSI addresses around
them?
The base value of the SW_MSI is only used by VFIO - are you trying to
use VFIO with this device, or have I misunderstood the dma-iommu.c
logic?
If it is only VFIO at issue then perhaps we should solve this by
completing the work Nicolin started to allow VFIO userspace to specify
the MSI Aperture?
Jason
next prev parent reply other threads:[~2025-09-23 16:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 15:45 [PATCH v4 0/4] arm-smmu: select suitable MSI IOVA Shyam Saini
2025-09-09 15:45 ` [PATCH v4 1/4] arm-smmu: move MSI_IOVA macro definitions Shyam Saini
2025-09-09 15:45 ` [PATCH v4 2/4] iommu/of: fix device tree configuration for PCI devices Shyam Saini
2025-09-24 17:44 ` Robin Murphy
2025-09-09 15:45 ` [PATCH v4 3/4] arm-smmu: select suitable MSI IOVA Shyam Saini
2025-09-18 16:49 ` Will Deacon
2025-09-18 22:43 ` Jason Gunthorpe
2025-09-19 7:33 ` Will Deacon
2025-09-19 12:08 ` Jason Gunthorpe
2025-09-23 15:56 ` Shyam Saini
2025-09-23 16:19 ` Jason Gunthorpe [this message]
2025-09-24 18:59 ` Robin Murphy
2025-09-09 15:46 ` [PATCH v4 4/4] drivers: iommu: refactor arm_smmu_get_resv_regions Shyam Saini
2025-09-09 15:58 ` Jason Gunthorpe
2025-09-15 16:28 ` Shyam Saini
2025-09-15 22:59 ` Jason Gunthorpe
2025-09-13 0:23 ` kernel test robot
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=20250923161912.GB2547959@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=bboscaccy@linux.microsoft.com \
--cc=clement.leger@bootlin.com \
--cc=code@tyhicks.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=eahariha@linux.microsoft.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.pan@linux.microsoft.com \
--cc=joro@8bytes.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lizhi.hou@amd.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.com \
--cc=shyamsaini@linux.microsoft.com \
--cc=thierry.reding@gmail.com \
--cc=vijayb@linux.microsoft.com \
--cc=virtualization@lists.linux.dev \
--cc=will@kernel.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