On Thu, Sep 28, 2017 at 10:11:21AM -0700, Raj, Ashok wrote:
> Hi Jean
>
> On Thu, Sep 28, 2017 at 12:21:34PM +0100, Jean-Philippe Brucker wrote:
> > It's the same problem on SMMUv3, all pointers in the multi-level PASID
> > tables are GPAs. Our solution was to grab chunks GPA space from the guest
> > when necessary.
>
> If pasid table is gPA and built and managed by guest IOMMU driver in case of
> vIOMMU, or virtio-iommu. Is this complex interaction to reserve memory and
> setup required? wouldn't it be sufficient if we do this.
>
> - Host advertises the capability in terms of what table format it it supports.
> - guest does all the memory allocation and management.
> - communicate to host via VFIO, gPA, format, size of table
> - host now programs context entries appropriately with proper nested mode
Yes, I think this is simpler than introducing a new memreserve API. The
code to build the pasid-tables is mostly there already, it just needs
some refactoring to make it usable for viommu.
The memreserve approach also implicates that the host can not trust the
pasid tables it builds and need to re-verify them on every change
because it is still accessible by the guest. We could write-protect the
table or unmap it from the guest, but it would still be accessible by
DMA. I think its tricky to get this right.
Regards,
Joerg
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
