Hi Shameer, On 11/14/24 09:48, Shameerali Kolothum Thodi wrote: > >> -----Original Message----- >> From: Nicolin Chen <[email protected]> >> Sent: Wednesday, November 13, 2024 6:31 PM >> To: Shameerali Kolothum Thodi <[email protected]> >> Cc: [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected]; >> [email protected]; Linuxarm <[email protected]>; Wangzhou (B) >> <[email protected]>; jiangkunkun <[email protected]>; >> Jonathan Cameron <[email protected]>; >> [email protected] >> Subject: Re: [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions >> to handle MSI nested binding >> >> On Fri, Nov 08, 2024 at 12:52:42PM +0000, Shameer Kolothum wrote: >>> From: Eric Auger <[email protected]> >>> >>> To handle SMMUv3 nested stage support it is practical to expose the >>> guest with reserved memory regions (RMRs) covering the IOVAs used by >>> the host kernel to map physical MSI doorbells. >> There has been an ongoing solution for MSI alternative: >> https://lore.kernel.org/kvm/[email protected]/ >> >> So, I think we should keep this patch out of this series, instead put it on >> top >> of the testing branch. > Yes. I think then we can support DT solution as well. > > On that MSI RFC above, have you seen Eric's earlier/initial proposal to bind > the Guest MSI in > nested cases. IIRC, it was providing an IOCTL and then creating a mapping in > the host. > > I think this is the latest on that. > https://lore.kernel.org/linux-iommu/[email protected]/ yes this is the latest before I stopped my VFIO integration efforts. > > But not sure, why we then moved to RMR approach. Eric?
This was indeed the 1st integration approach. Using RMR instead was suggested by Jean-Philippe and I considered it as simpler (because we needed the SET_MSI_BINDING iotcl) so I changed the approach. Thanks Eric > > Thanks, > Shameer >
