On Thu, Feb 20, 2025 at 10:58:05AM +0800, Baolu Lu wrote: > On 2/19/25 18:35, Jean-Philippe Brucker wrote: > > 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. > > Are you talking about ECS mode? There is no hardware or software Thanks, Baolu. I suppose so (by 'legacy', Jean was refers to ECS, and he knows this is no longer supported). > implementation for this mode, so we don't need to consider it. It seems we have now reached a consensus that no PASID table needs to be managed by a pvIOMMU for VT-d. Meanwhile, it's worth noting that this is not the case for ARM SMMUv3, which is the opposite. And as to AMD IOMMU, we may choose either. B.R. Yu
