On 2025/2/19 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.
that's correct. It was called ECS mode and has already been deprecated.
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.
Conceptually, ATTACH_PASID_TABLE does not suit here as the PASID table is
maintained by host. It may need an ATTACH_PASID thing which is triggered
per guest PASID table entry setup/update/destroy.
--
Regards,
Yi Liu
