On Wed, Feb 19, 2025 at 05:39:19PM +0800, Yu Zhang wrote: > 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? No, the proposal for managing the PASID table in the host was done before the VT-d architecture added Scalable mode, so at the time they also had to assign whole PASID tables to the guest and weren't keen on managing it in the host. I believe in revision 3 (2018) the architecture added support for Scalable mode and the ability to manage PASID tables in the host. Nowadays it wouldn't make sense for a pvIOMMU to manage the VT-d PASID tables in the guest, because as I understand it there is no demand for supporting the legacy mode address translation of VT-d. Thanks, Jean
