On Thu, Feb 13, 2025 at 06:09:19PM +0000, Jean-Philippe Brucker wrote: > On Fri, Feb 14, 2025 at 01:03:43AM +0800, Yu Zhang wrote: > > On Thu, Feb 13, 2025 at 09:46:01AM +0000, Jean-Philippe Brucker wrote: > > > Hi Jacob, > > > > > > On Wed, Feb 12, 2025 at 09:47:23PM -0800, Jacob Pan wrote: > > > > Our code and backend support are still in the early stages, that is why > > > > I am attempting to convert virtio-iommu driver to iommu_pt. Not sure if > > > > anyone has done the QEMU part to support VIRTIO_IOMMU_F_ATTACH_TABLE? > > > > @Jean @Eric Do you know? > > > > > > As far as I know Tina worked on this most recently: > > > https://github.com/TinaZhangZW/qemu/commits/virtio-iommu/vt-d-pgtable/ > > > https://lore.kernel.org/all/20231106071226.9656-1-tina.zhang@xxxxxxxxx/ > > > > Thanks a lot for this information, Jean. > > IIUC, these patches were trying to add VT-d IO page table support in > > virtio-iommu, but it is not based on Jason's generic PT [1]. Just wondering, > > does anyone have plan to do the incorporation? > > I'm not aware of anyone working on this at the moment. Something you will > need for a portable pviommu is a library that manages PASID tables rather > than page tables [1], because the Arm SMMUv3 arch only support assigning > PASID tables to the guest. Alternatively you could implement opaque PASID > table allocation via host calls, letting the guest allocate GPA space and > the host manage the PASID table, but that idea didn't seem very popular at > the time. Thank you, Jean. Just had a study of the spec. For ARM SMMUv3, letting the guest manage the PASID table, and then assigning it directly to the backend in ATTACH_TABLE request looks quite resonable. But for VT-d, my understanding is the PASID table shall be managed by host. By "that idea didn't seem very popular", do you mean that people also want the ATTCH_TABLE request for VT-d also assign the PASID table(an virtual one managed by the guest). If yes, why? > > Thanks, > Jean > > [1] https://lore.kernel.org/all/20210115121342.15093-1-vivek.gautam@xxxxxxx/ > B.R. Yu
