Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:m...@kernel.org] > Sent: 04 June 2021 14:55 > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > Cc: linux-arm-ker...@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > linux-ker...@vger.kernel.org; w...@kernel.org; catalin.mari...@arm.com; > james.mo...@arm.com; julien.thierry.k...@gmail.com; > suzuki.poul...@arm.com; jean-phili...@linaro.org; Alexandru Elisei > <alexandru.eli...@arm.com>; Linuxarm <linux...@huawei.com> > Subject: Re: [RFC PATCH 0/3] kvm/arm: New VMID allocator based on asid(2nd > approach) > > On Fri, 04 Jun 2021 09:13:10 +0100, > Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > wrote: > > > > Hi, > > > > > -----Original Message----- > > > From: Shameerali Kolothum Thodi > > > Sent: 06 May 2021 17:52 > > > To: linux-arm-ker...@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > > > linux-ker...@vger.kernel.org > > > Cc: m...@kernel.org; w...@kernel.org; catalin.mari...@arm.com; > > > james.mo...@arm.com; julien.thierry.k...@gmail.com; > > > suzuki.poul...@arm.com; jean-phili...@linaro.org; Linuxarm > > > <linux...@huawei.com> > > > Subject: [RFC PATCH 0/3] kvm/arm: New VMID allocator based on asid(2nd > > > approach) > > > > > > This is based on a suggestion from Will [0] to try out the asid > > > based kvm vmid solution as a separate VMID allocator instead of > > > the shared lib approach attempted in v4[1]. > > > > > > The idea is to compare both the approaches and see whether the > > > shared lib solution with callbacks make sense or not. > > > > A gentle ping on this. Please take a look and let me know. > > I had a look and I don't overly dislike it. I'd like to see the code > without the pinned stuff though, at least to ease the reviewing. I > haven't tested it in anger, but I have pushed the rebased code at [1] > as it really didn't apply to 5.13-rc4.
Thanks for taking a look and the rebase. I will remove the pinned stuff in the next revision as that was added just to compare against the previous version. > > One thing I'm a bit worried about is that we so far relied on VMID 0 > never being allocated to a guest, which is now crucial for protected > KVM. I can't really convince myself that this can never happen with > this. Hmm..not sure I quite follow that. As per the current logic vmid 0 is reserved and is not allocated to Guest. > Plus, I've found this nugget: > > <quote > max_pinned_vmids = NUM_USER_VMIDS - num_possible_cpus() - 2; > </quote> > > What is this "- 2"? My hunch is that it should really be "- 1" as VMID > 0 is reserved, and we have no equivalent of KPTI for S2. I think this is more related to the "pinned vmid" stuff and was borrowed from the asid_update_limit() fn in arch/arm64/mm/context.c. But I missed the comment that explains the reason behind it. It says, ---x--- /* * There must always be an ASID available after rollover. Ensure that, * even if all CPUs have a reserved ASID and the maximum number of ASIDs * are pinned, there still is at least one empty slot in the ASID map. */ max_pinned_asids = num_available_asids - num_possible_cpus() - 2; ---x--- So this is to make sure we will have at least one VMID available after rollover in case we have pinned the max number of VMIDs. I will include that comment to make it clear. Thanks, Shameer > > M. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h > =kvm-arm64/mmu/vmid > > -- > 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