Messages in this thread | | | Date | Fri, 04 Jun 2021 16:27:39 +0100 | From | Marc Zyngier <> | Subject | Re: [RFC PATCH 0/3] kvm/arm: New VMID allocator based on asid(2nd approach) |
| |
On Fri, 04 Jun 2021 15:51:29 +0100, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> wrote: > > Hi Marc, > > > -----Original Message----- > > From: Marc Zyngier [mailto:maz@kernel.org] > > Sent: 04 June 2021 14:55 > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> > > Cc: linux-arm-kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > > linux-kernel@vger.kernel.org; will@kernel.org; catalin.marinas@arm.com; > > james.morse@arm.com; julien.thierry.kdev@gmail.com; > > suzuki.poulose@arm.com; jean-philippe@linaro.org; Alexandru Elisei > > <Alexandru.Elisei@arm.com>; Linuxarm <linuxarm@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.thodi@huawei.com> > > wrote: > > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: Shameerali Kolothum Thodi > > > > Sent: 06 May 2021 17:52 > > > > To: linux-arm-kernel@lists.infradead.org; kvmarm@lists.cs.columbia.edu; > > > > linux-kernel@vger.kernel.org > > > > Cc: maz@kernel.org; will@kernel.org; catalin.marinas@arm.com; > > > > james.morse@arm.com; julien.thierry.kdev@gmail.com; > > > > suzuki.poulose@arm.com; jean-philippe@linaro.org; Linuxarm > > > > <linuxarm@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.
And that's the bit I'm struggling to validate here. I guess it works because cur_idx is set to 1 in new_vmid().
> > > 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.
That doesn't really explain the -2. Or is that that we have one for the extra empty slot, and one for the reserved?
Jean-Philippe?
Thanks,
M.
-- Without deviation from the norm, progress is not possible.
| |