On Fri, Mar 29, 2024 at 11:55:50AM +0800, Jason Wang wrote: > On Wed, Mar 27, 2024 at 5:08 PM Jason Wang <jasowang@xxxxxxxxxx> wrote: > > > > On Thu, Mar 21, 2024 at 3:00 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > > > On Wed, Mar 20, 2024 at 06:19:12PM +0800, Wang Rong wrote: > > > > From: Rong Wang <w_angrong@xxxxxxx> > > > > > > > > Once enable iommu domain for one device, the MSI > > > > translation tables have to be there for software-managed MSI. > > > > Otherwise, platform with software-managed MSI without an > > > > irq bypass function, can not get a correct memory write event > > > > from pcie, will not get irqs. > > > > The solution is to obtain the MSI phy base address from > > > > iommu reserved region, and set it to iommu MSI cookie, > > > > then translation tables will be created while request irq. > > > > > > > > Change log > > > > ---------- > > > > > > > > v1->v2: > > > > - add resv iotlb to avoid overlap mapping. > > > > v2->v3: > > > > - there is no need to export the iommu symbol anymore. > > > > > > > > Signed-off-by: Rong Wang <w_angrong@xxxxxxx> > > > > > > There's in interest to keep extending vhost iotlb - > > > we should just switch over to iommufd which supports > > > this already. > > > > IOMMUFD is good but VFIO supports this before IOMMUFD. This patch > > makes vDPA run without a backporting of full IOMMUFD in the production > > environment. I think it's worth. > > > > If you worry about the extension, we can just use the vhost iotlb > > existing facility to do this. > > > > Thanks > > Btw, Wang Rong, > > It looks that Cindy does have the bandwidth in working for IOMMUFD support. I think you mean she does not. > Do you have the will to do that? > > Thanks
