On Wed, Feb 19, 2025 at 07:11:43PM +0800, Yu Zhang wrote: > 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.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. 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)? I don't know either, but given that the parts about AMD and RISC-V in the proposal haven't received feedback they will definitely change, and it's a question for AMD and RISC-V people. Thanks, Jean
