From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7CF50C07E94 for ; Fri, 4 Jun 2021 14:53:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4A90B613AA for ; Fri, 4 Jun 2021 14:53:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A90B613AA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XTo2ow8PDHq5NX8gz+AA/3zAbQQRbhj6WCJiCQ0wP2Y=; b=k4dFfyn1b8rifl qLG3YJTYa+RYoZOPFlti3zveiqqPVWb0h8N/EVoImjOTHon3HyKg/i5v3GIlic0Im9oCkwTiD9fjU +lo2W6tAwgOfqcqeMNyQqQRcmip3jL5lj5xdCrNj9y/Ak6/mf49Jf9V+9nslhtEfAni42mKf60b7h wR4gAHBy+ashmrMJVfB9/kAnvOXK8dFTePorR1JrcS8eQ//jnKHE0cgFrRotfD1Zs4V/6HskXtXxH Fo7sjeKNpwPEvgm1QCFEaLhOAylTfcsWRwRx5tRbXO2dGf6GmSlCUGgO7qplvrj+opNo5J9jHRFs6 NAlhJN0Ez7s/2QY4te3w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lpBAp-00E0Pl-Na; Fri, 04 Jun 2021 14:51:47 +0000 Received: from szxga08-in.huawei.com ([45.249.212.255]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lpBAl-00E0Mk-6L for linux-arm-kernel@lists.infradead.org; Fri, 04 Jun 2021 14:51:45 +0000 Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4FxQZZ31Y7z1BHbD; Fri, 4 Jun 2021 22:46:46 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 22:51:32 +0800 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 22:51:31 +0800 Received: from lhreml710-chm.china.huawei.com ([169.254.81.184]) by lhreml710-chm.china.huawei.com ([169.254.81.184]) with mapi id 15.01.2176.012; Fri, 4 Jun 2021 15:51:29 +0100 From: Shameerali Kolothum Thodi To: Marc Zyngier 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 , Linuxarm Subject: RE: [RFC PATCH 0/3] kvm/arm: New VMID allocator based on asid(2nd approach) Thread-Topic: [RFC PATCH 0/3] kvm/arm: New VMID allocator based on asid(2nd approach) Thread-Index: AQHXQph5pwodb0a/4kShAMz7Pnc+rqsDq0rQgABREYCAABlY4A== Date: Fri, 4 Jun 2021 14:51:29 +0000 Message-ID: <95bb84ffdb0f4db3b64b38cc3b651f90@huawei.com> References: <20210506165232.1969-1-shameerali.kolothum.thodi@huawei.com> <87sg1xzqea.wl-maz@kernel.org> In-Reply-To: <87sg1xzqea.wl-maz@kernel.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.88.52] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210604_075143_733972_84CBE0A1 X-CRM114-Status: GOOD ( 28.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Marc, > -----Original Message----- > From: Marc Zyngier [mailto:maz@kernel.org] > Sent: 04 June 2021 14:55 > To: Shameerali Kolothum Thodi > 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 > ; Linuxarm > 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 > 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 > > > > > > 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: > > max_pinned_vmids = NUM_USER_VMIDS - num_possible_cpus() - 2; > > > 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel