[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250129150454.GH5556@nvidia.com>
Date: Wed, 29 Jan 2025 11:04:54 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Eric Auger <eric.auger@...hat.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>,
Nicolin Chen <nicolinc@...dia.com>,
"will@...nel.org" <will@...nel.org>,
"robin.murphy@....com" <robin.murphy@....com>,
"kevin.tian@...el.com" <kevin.tian@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"maz@...nel.org" <maz@...nel.org>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"joro@...tes.org" <joro@...tes.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"reinette.chatre@...el.com" <reinette.chatre@...el.com>,
"yebin (H)" <yebin10@...wei.com>,
"apatel@...tanamicro.com" <apatel@...tanamicro.com>,
"shivamurthy.shastri@...utronix.de" <shivamurthy.shastri@...utronix.de>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"anna-maria@...utronix.de" <anna-maria@...utronix.de>,
"yury.norov@...il.com" <yury.norov@...il.com>,
"nipun.gupta@....com" <nipun.gupta@....com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"mdf@...nel.org" <mdf@...nel.org>,
"mshavit@...gle.com" <mshavit@...gle.com>,
"smostafa@...gle.com" <smostafa@...gle.com>,
"ddutile@...hat.com" <ddutile@...hat.com>
Subject: Re: [PATCH RFCv2 00/13] iommu: Add MSI mapping support with nested
SMMU
On Wed, Jan 29, 2025 at 03:54:48PM +0100, Eric Auger wrote:
> >> or you are just mentioning it here because
> >> it is still possible to make use of that. I think from previous discussions the
> >> argument was to adopt a more dedicated MSI pass-through model which I
> >> think is approach-2 here.
> > The basic flow of the pass through model is shown in the last two
> > patches, it is not fully complete but is testable. It assumes a single
> > ITS page. The VM would use IOMMU_OPTION_SW_MSI_START/SIZE to put the
> > ITS page at the correct S2 location and then describe it in the ACPI
> > as an ITS page not a RMR.
> This is a nice to have feature but not mandated in the first place,
> is it?
Not mandated. It just sort of happens because of the design. IMHO
nothing should use it because there is no way for userspace to
discover how many ITS pages there may be.
> > This missing peice is cleaning up the ITS mapping to allow for
> > multiple ITS pages. I've imagined that kvm would someone give iommufd
> > a FD that holds the specific ITS pages instead of the
> > IOMMU_OPTION_SW_MSI_START/SIZE flow.
> That's what I don't get: at the moment you only pass the gIOVA. With
> technique 2, how can you build the nested mapping, ie.
>
> S1 S2
> gIOVA -> gDB -> hDB
>
> without passing the full gIOVA/gDB S1 mapping to the host?
The nested S2 mapping is already setup before the VM boots:
- The VMM puts the ITS page (hDB) into the S2 at a fixed address (gDB)
- The ACPI tells the VM that the GIC has an ITS page at the S2's
address (hDB)
- The VM sets up its S1 with a gIOVA that points to the S2's ITS
page (gDB). The S2 already has gDB -> hDB.
- The VMM traps the gIOVA write to the MSI-X table. Both the S1 and
S2 are populated at this moment.
If you have multiple ITS pages then the ACPI has to tell the guest GIC
about them, what their gDB address is, and what devices use which ITS.
Jason
Powered by blists - more mailing lists