[RFC PATCH 3/5] KVM: ARM64: Add support for pinned VMIDs

[Shameerali Kolothum Thodi]

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier [mailto:maz at kernel.org]
> Sent: 09 March 2021 10:33
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
> Cc: linux-arm-kernel at lists.infradead.org; iommu at lists.linux-foundation.org;
> kvmarm at lists.cs.columbia.edu; alex.williamson at redhat.com;
> jean-philippe at linaro.org; eric.auger at redhat.com; zhangfei.gao at linaro.org;
> Jonathan Cameron <jonathan.cameron at huawei.com>; Zengtao (B)
> <prime.zeng at hisilicon.com>; linuxarm at openeuler.org; Will Deacon
> <will at kernel.org>
> Subject: Re: [RFC PATCH 3/5] KVM: ARM64: Add support for pinned VMIDs
> 
> Hi Shameer,
> 
> [+Will]
> 
> On Mon, 22 Feb 2021 15:53:36 +0000,
> Shameer Kolothum <shameerali.kolothum.thodi at huawei.com> wrote:
> >
> > On an ARM64 system with a SMMUv3 implementation that fully supports
> > Broadcast TLB Maintenance(BTM) feature, the CPU TLB invalidate
> > instructions are received by SMMU. This is very useful when the
> > SMMU shares the page tables with the CPU(eg: Guest SVA use case).
> > For this to work, the SMMU must use the same VMID that is allocated
> > by KVM to configure the stage 2 translations.
> >
> > At present KVM VMID allocations are recycled on rollover and may
> > change as a result. This will create issues if we have to share
> > the KVM VMID with SMMU. Hence, we spilt the KVM VMID space into
> > two, the first half follows the normal recycle on rollover policy
> > while the second half of the VMID pace is used to allocate pinned
> > VMIDs. This feature is enabled based on a command line option
> > "kvm-arm.pinned_vmid_enable".
> 
> I think this is the wrong approach. Instead of shoving the notion of
> pinned VMID into the current allocator, which really isn't designed
> for this, it'd be a lot better if we aligned the KVM VMID allocator
> with the ASID allocator, which already has support for pinning and is
> in general much more efficient.

Ok. Agree that this is not efficient, but was easy to prototype something :)

> Julien Grall worked on such a series[1] a long while ago, which got
> stalled because of the 32bit KVM port. Since we don't have this burden
> anymore, I'd rather you look in that direction instead of wasting half
> of the VMID space on potentially pinned VMIDs.

Sure. I will check that and work on it.

Thanks,
Shameer

> Thanks,
> 
> 	M.
> 
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190724162534
> .7390-1-julien.grall at arm.com/
> 
> 
> --
> Without deviation from the norm, progress is not possible.