Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:maz@xxxxxxxxxx] > Sent: 09 March 2021 10:33 > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; > kvmarm@xxxxxxxxxxxxxxxxxxxxx; alex.williamson@xxxxxxxxxx; > jean-philippe@xxxxxxxxxx; eric.auger@xxxxxxxxxx; zhangfei.gao@xxxxxxxxxx; > Jonathan Cameron <jonathan.cameron@xxxxxxxxxx>; Zengtao (B) > <prime.zeng@xxxxxxxxxxxxx>; linuxarm@xxxxxxxxxxxxx; Will Deacon > <will@xxxxxxxxxx> > 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@xxxxxxxxxx> 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@xxxxxxx/ > > > -- > Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
