[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250123132432.GJ5556@nvidia.com>
Date: Thu, 23 Jan 2025 09:24:32 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>
Cc: 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>,
"eric.auger@...hat.com" <eric.auger@...hat.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 Thu, Jan 23, 2025 at 09:06:49AM +0000, Shameerali Kolothum Thodi wrote:
> One confusion I have about the above text is, do we still plan to support the
> approach -1( Using RMR in Qemu)
Yes, it remains an option. The VMM would use the
IOMMU_OPTION_SW_MSI_START/SIZE ioctls to tell the kernel where it
wants to put the RMR region then it would send the RMR into the VM
through ACPI.
The kernel side promises that the RMR region will have a consistent
(but unpredictable!) layout of ITS pages (however many are required)
within that RMR space, regardless of what devices/domain are attached.
I would like to start with patches up to #10 for this part as it
solves two of the three problems here.
> 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.
The VMM will capture the MSI writes and use
VFIO_IRQ_SET_ACTION_PREPARE to convey the guests's S1 translation to
the IRQ subsystem.
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.
Jason
Powered by blists - more mailing lists