On Fri, 04 Jun 2021 15:51:29 +0100, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> wrote: > > Hi Marc, > > > -----Original Message----- > > From: Marc Zyngier [mailto:maz@xxxxxxxxxx] > > Sent: 04 June 2021 14:55 > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> > > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx; > > linux-kernel@xxxxxxxxxxxxxxx; will@xxxxxxxxxx; catalin.marinas@xxxxxxx; > > james.morse@xxxxxxx; julien.thierry.kdev@xxxxxxxxx; > > suzuki.poulose@xxxxxxx; jean-philippe@xxxxxxxxxx; Alexandru Elisei > > <Alexandru.Elisei@xxxxxxx>; Linuxarm <linuxarm@xxxxxxxxxx> > > 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@xxxxxxxxxx> > > wrote: > > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: Shameerali Kolothum Thodi > > > > Sent: 06 May 2021 17:52 > > > > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx; > > > > linux-kernel@xxxxxxxxxxxxxxx > > > > Cc: maz@xxxxxxxxxx; will@xxxxxxxxxx; catalin.marinas@xxxxxxx; > > > > james.morse@xxxxxxx; julien.thierry.kdev@xxxxxxxxx; > > > > suzuki.poulose@xxxxxxx; jean-philippe@xxxxxxxxxx; Linuxarm > > > > <linuxarm@xxxxxxxxxx> > > > > 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. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
