Re: [RFC PATCH v2 4/7] iommufd: Associate kvm pointer to iommufd ctx

[Oliver Upton <oliver.upton@linux.dev>]

On Mon, Jun 24, 2024 at 12:29:07PM -0700, Sean Christopherson wrote:
> On Mon, Jun 24, 2024, Oliver Upton wrote:
> > On Mon, Jun 24, 2024 at 03:01:48PM -0300, Jason Gunthorpe wrote:
> > > If KVM can change VMID on the fly then that is a further complication
> > > :\
> 
> Ya, as written today, KVM doesn't assign a VMID when the VM is created, and instead
> allocates VMIDs on-demand when a vCPU is run.
> 
> The KVM changes in this series allow "pinning" the currently assigned VMID, i.e.
> tries to address that further complication.  But because of the on-demand
> allocation, there might not be a currently assigned VMID for VM, or the VMID might
> be stale, i.e. re-assigned to a different VM.
> 
> Thus, kvm_arm_pinned_vmid_get() can effectively trigger VMID allocations, and
> thus cgroup charging and failure.
> 
> If I'm reading the ARM code correctly, the intent is to cycle through VMIDs as  
> necessary so that it's possible for every actively running VM to have a VMID.
> And maybe also to also minimize the number of TLB + I$ invalidations?

The commentary about TLBIs + I$ invalidations is in relation to how
rollover is handled. The kernel's ASID allocator does some deferred
invalidation, the VMID allocator does some eager invalidation at rollover
because it is believed to be a rarer occurrence.

But generally speaking, it's what you expect, we have some structures in
hardware that use VMID to form a tag, and we wnat to avoid blasting them
if at all possible.

> > > 
> > > > Hmm, kvm_arm_pinned_vmid_get() doesn't fail, it just falls back to VMID=0.  Which
> > > > seems odd.
> > 
> > This is bleeding a bit of implementation detail where VMID=0 is known to
> > be reserved (thus invalid), it'd probably be better if the
> > implementation actually just returned an error.
> 
> Oof, I assumed using VMID=0 just caused a loss of performance, but this makes
> it sound like the IOMMU mappings will fault?

Bit worse than that :)

Having the SMMU participate in broadcast TLB maintenance means TLBI
instructions on the CPU invalidate translations in the SMMU, which is
useful for SVA usecases. However, if the host is using different VMIDs
for the CPU and SMMU, then guest TLBIs no longer match the guest's SMMU
context...

Pinning / sharing the VMID between CPU and SMMU is a hard requirement if
you advertise BTM support to the guest.

-- 
Thanks,
Oliver