On Mon, Jun 10, 2024 at 10:49 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
>
> On Fri, May 31, 2024 at 02:25:15PM +0800, Zong Li wrote:
>
> > > +static void riscv_iommu_iodir_update(struct riscv_iommu_device *iommu,
> > > + struct device *dev, u64 fsc, u64 ta)
> > > +{
> > > + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > > + struct riscv_iommu_dc *dc;
> > > + u64 tc;
> > > + int i;
> > > +
> > > + /* Device context invalidation ignored for now. */
> > > +
> > > + /*
> > > + * For device context with DC_TC_PDTV = 0, translation attributes valid bit
> > > + * is stored as DC_TC_V bit (both sharing the same location at BIT(0)).
> > > + */
> > > + for (i = 0; i < fwspec->num_ids; i++) {
> > > + dc = riscv_iommu_get_dc(iommu, fwspec->ids[i]);
> > > + tc = READ_ONCE(dc->tc);
> > > + tc |= ta & RISCV_IOMMU_DC_TC_V;
> > > +
> > > + WRITE_ONCE(dc->fsc, fsc);
> > > + WRITE_ONCE(dc->ta, ta & RISCV_IOMMU_PC_TA_PSCID);
> > > + /* Update device context, write TC.V as the last step. */
> > > + dma_wmb();
> > > + WRITE_ONCE(dc->tc, tc);
> > > + }
> >
> > Does it make sense to invalidate the DDTE after we update the DDTE in
> > memory? This behavior will affect the nested IOMMU mechanism. The VMM
> > has to catch the event of a DDTE update from the guest and then
> > eventually go into the host IOMMU driver to configure the IOMMU
> > hardware.
>
> Right, this is why I asked about negative caching.
>
> The VMMs are a prime example of negative caching, in something like
> the SMMU implementation the VMM will cache the V=0 STE until they see
> an invalidation.
>
> Driving the VMM shadowing/caching entirely off of the standard
> invalidation mechanism is so much better than any other option.
>
> IMHO you should have the RISCV spec revised to allow negative caching
> in any invalidated data structure to permit the typical VMM design
> driven off of shadowing triggered by invalidation commands.
>
> Once the spec permits negative caching then the software would have to
> invalidate after going V=0 -> V=1.
>
> Jason
Allowing negative cacheing by the spec (e.g. for VMM use cases) and
documenting required invalidation sequences would definitely help
here. I'm hesitating adding IODIR.INVAL that is not required by the
spec [1], but this is something that can be controlled by a
capabilities/feature bit once added to the specification or based on
VID:DID of the emulated Risc-V IOMMU.
Another option to consider for VMM is to utilize the WARL property of
DDTP, and provide fixed location of the single level DDTP, pointing to
MMIO region, where DDTE updates will result in vmm exit / fault
handler. This will likely not be as efficient as IODIR.INVAL issued
for any DDTE updates.
[1] https://github.com/riscv-non-isa/riscv-iommu/blob/main/src/iommu_data_structures.adoc#caching-in-memory-data-structures
- Tomasz
