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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D711DC77B60 for ; Sun, 23 Apr 2023 13:28:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229564AbjDWN21 (ORCPT ); Sun, 23 Apr 2023 09:28:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjDWN2Y (ORCPT ); Sun, 23 Apr 2023 09:28:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05CD11708; Sun, 23 Apr 2023 06:28:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 93D4460DEA; Sun, 23 Apr 2023 13:28:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C98ADC433D2; Sun, 23 Apr 2023 13:28:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682256502; bh=eFNb+a+GhOZTCzL6BnbhdUtc1LYfBYZOBZ5qeNc+68U=; h=Date:To:Cc:Subject:From:References:In-Reply-To:From; b=ZDKsKjGh0x+GZoRl/oHVyQhx0ln/3K8eLSV9C3hvv3u5o4qXAstvPNpUVSbuL4PDu OrdvyqTEsBo3QJPYCLDyX5pkzEzMn09VfQTNw+WxBfSuqXR6Ck0GIueTI2m8MbD/Ly H8KcVBgXurKBJ0ZzsOv9tHrohHnuUSdsysfWHXULw64VR8g0kXGXViJeULoJt1oA8/ yaCp4mc6/zATZ2nXPqX/jE/eFRPAYcxaSbC9I7F6A3QTXKIFqyqPqpQY9DZE2j7sOR nLUkZ9TmecECY+gKtj6TBJySrvz7AGzr8bq2NElAiRctKmNrR6hqDz5w17e32cGd+r fng21RJhF3tKw== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sun, 23 Apr 2023 16:28:16 +0300 Message-Id: To: "David Hildenbrand" , "Sean Christopherson" , "Chao Peng" Cc: "Paolo Bonzini" , "Vitaly Kuznetsov" , "Jim Mattson" , "Joerg Roedel" , "Maciej S . Szmigiero" , "Vlastimil Babka" , "Vishal Annapurve" , "Yu Zhang" , "Kirill A . Shutemov" , , "Quentin Perret" , , "Michael Roth" , , "Mike Rapoport" , "Liam Merwick" , "Isaku Yamahata" , "Ackerley Tng" , , Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) From: "Jarkko Sakkinen" X-Mailer: aerc 0.14.0 References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <658018f9-581c-7786-795a-85227c712be0@redhat.com> In-Reply-To: <658018f9-581c-7786-795a-85227c712be0@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon Apr 17, 2023 at 6:48 PM EEST, David Hildenbrand wrote: > On 17.04.23 17:40, Sean Christopherson wrote: > > What do y'all think about renaming "restrictedmem" to "guardedmem"? > > Yeay, let's add more confusion :D > > If we're at renaming, I'd appreciate if we could find a terminology that= =20 > does look/sound less horrible. > > >=20 > > I want to start referring to the code/patches by its syscall/implementa= tion name > > instead of "UPM", as "UPM" is (a) very KVM centric, (b) refers to the b= roader effort > > and not just the non-KVM code, and (c) will likely be confusing for fut= ure reviewers > > since there's nothing in the code that mentions "UPM" in any way. > >=20 > > But typing out restrictedmem is quite tedious, and git grep shows that = "rmem" is > > already used to refer to "reserved memory". > >=20 > > Renaming the syscall to "guardedmem"... > > restrictedmem, guardedmem, ... all fairly "suboptimal" if you'd ask me ..= . In the world of TEE's and confidential computing it is fairly common to call memory areas enclaves, even outside SGX context. So in that sense enclave memory would be the most correct terminology. BR, Jarkko