Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:m...@kernel.org] > Sent: 09 March 2021 10:33 > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > Cc: linux-arm-ker...@lists.infradead.org; io...@lists.linux-foundation.org; > kvmarm@lists.cs.columbia.edu; alex.william...@redhat.com; > jean-phili...@linaro.org; eric.au...@redhat.com; zhangfei....@linaro.org; > Jonathan Cameron <jonathan.came...@huawei.com>; Zengtao (B) > <prime.z...@hisilicon.com>; linux...@openeuler.org; Will Deacon > <w...@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.th...@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.gr...@arm.com/ > > > -- > Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
