Re: [PATCH 3/5] iommu/virtio: Move to domain_alloc_paging()

Yu Zhang
2025-02-19T09:39:23Z

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@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?
>
> Thanks,
> Jean
>
> [1] https://lore.kernel.org/all/20210115121342.15093-1-vivek.gautam@arm.com/
>

B.R.
Yu