On Thu, Nov 14, 2024 at 11:41:58AM +0100, Eric Auger wrote: > Hi Shameer, > > On 11/14/24 09:48, Shameerali Kolothum Thodi wrote: > > > >> -----Original Message----- > >> From: Nicolin Chen <nicol...@nvidia.com> > >> Sent: Wednesday, November 13, 2024 6:31 PM > >> To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > >> Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; > >> eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com; > >> ddut...@redhat.com; Linuxarm <linux...@huawei.com>; Wangzhou (B) > >> <wangzh...@hisilicon.com>; jiangkunkun <jiangkun...@huawei.com>; > >> Jonathan Cameron <jonathan.came...@huawei.com>; > >> zhangfei....@linaro.org > >> 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 <eric.au...@redhat.com> > >>> > >>> 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/cover.1731130093.git.nicol...@nvidia.com/ > >> > >> 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/20210411114659.15051-4-eric.au...@redhat.com/ > 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.
Oh, I didn't realized Eric had this.. Now, Robin wanted it back (in iommufd though), against the RMR :-/ Nicolin