RE: [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding

[Shameerali Kolothum Thodi via]

> -----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/

But not sure, why we then moved to RMR approach. Eric?

Thanks,
Shameer