On Wed, Feb 19, 2025 at 10:35:18AM +0000, 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.zh...@intel.com/ > > > > > > > > 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. Yeah, my understanding is that old revisions of VT-d looks more like the ARM SMMUv3. But with scalable mode introduced, there's no need for a pvIOMMU to allocate a guest version PASID table on VT-d. So my question becomes: why do we need a library that manages PASID tables in the guest? To also support AMD IOMMU besides ARM SMMUv3( I saw your spec proposed both ATTACH_TABLE request for AMD GCR3 table and ATTACH_TABLE request for AMD page table, but don't know which one is more preferred in practice)? B.R. Yu > > Thanks, > Jean
