Re: [RFC PATCH 0/4] Use 1st-level for DMA remapping in guest

[Lu Baolu]

Hi,

On 9/24/19 4:25 AM, Raj, Ashok wrote:
> Hi Jacob
>
> On Mon, Sep 23, 2019 at 12:27:15PM -0700, Jacob Pan wrote:
> > > In VT-d 3.0, scalable mode is introduced, which offers two level
> > > translation page tables and nested translation mode. Regards to
> > > GIOVA support, it can be simplified by 1) moving the GIOVA support
> > > over 1st-level page table to store GIOVA->GPA mapping in vIOMMU,
> > > 2) binding vIOMMU 1st level page table to the pIOMMU, 3) using pIOMMU
> > > second level for GPA->HPA translation, and 4) enable nested (a.k.a.
> > > dual stage) translation in host. Compared with current shadow GIOVA
> > > support, the new approach is more secure and software is simplified
> > > as we only need to flush the pIOMMU IOTLB and possible device-IOTLB
> > > when an IOVA mapping in vIOMMU is torn down.
> > >
> > >       .-----------.
> > >       |  vIOMMU   |
> > >       |-----------|                 .-----------.
> > >       |           |IOTLB flush trap |   QEMU    |
> > >       .-----------.    (unmap)      |-----------|
> > >       | GVA->GPA  |---------------->|           |
> > >       '-----------'                 '-----------'
> > >       |           |                       |
> > >       '-----------'                       |
> > >             <------------------------------
> > >             |      VFIO/IOMMU
> > >             |  cache invalidation and
> > >             | guest gpd bind interfaces
> > >             v
> > For vSVA, the guest PGD bind interface will mark the PASID as guest
> > PASID and will inject page request into the guest. In FL gIOVA case, I
> > guess we are assuming there is no page fault for GIOVA. I will need to
> > add a flag in the gpgd bind such that any PRS will be auto responded
> > with invalid.
>
> Is there real need to enforce this? I'm not sure if there is any
> limitation in the spec, and if so, can the guest check that instead?

For FL gIOVA case, gPASID is always 0. If a physical device is passed
through, hPASID is also 0; If an mdev device (representing an ADI)
instead, hPASID would be the PASID corresponding to the ADI. The
simulation software (i.e. QEMU) maintains a map between gPASID and
hPASID.

I second Ashok's idea. We don't need to distinguish these two cases in
the api and handle page request interrupt in guest as an unrecoverable
one.

> Also i believe the idea is to overcommit PASID#0 such uses. Thought
> we had a capability to expose this to the vIOMMU as well. Not sure if this
> is already documented, if not should be up in the next rev.
>
>
> > Also, native use of IOVA FL map is not to be supported? i.e. IOMMU API
> > and DMA API for native usage will continue to be SL only?
> > >       .-----------.
> > >       |  pIOMMU   |
> > >       |-----------|
> > >       .-----------.
> > >       | GVA->GPA  |<---First level
> > >       '-----------'
> > >       | GPA->HPA  |<---Scond level
>
> s/Scond/Second

Yes. Thanks!

Best regards,
Baolu