Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1908441rwr; Sat, 6 May 2023 00:57:36 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5R8H91rYtEIho7tbo9mG7Uatvc74djqNdVoHjwA6Evj6xixITsOn/u8y2xkM/+acP1HaUo X-Received: by 2002:a05:6a00:1acf:b0:643:d40c:7da0 with SMTP id f15-20020a056a001acf00b00643d40c7da0mr642481pfv.31.1683359855800; Sat, 06 May 2023 00:57:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683359855; cv=none; d=google.com; s=arc-20160816; b=RHF8Ng1/mm1Vz5p5egbHUWva1jBBTnyFM7/pb1syO8vxJTqd6JWw4qmlthqRohKT1v gU9oJ19jtE2PaqL6M0IVFObs0mewCD3QYt8jnYT1eIQEJFIvEUwaztoayeOhI0o88Jkd 5WAHIxG5qxGRtYYVl/AKj9BD8w4s0R7NA2oorpPKUqRjzWS8wAaUsnUyEDdDh3K95B73 GtfDRQv3MEZ5TclzCrn0ldYWpdpqOFfDTnGef/j9ORCQbFh3My7Sot1vIAPW72e3U0vB wzknodgCBQ3QQ2m3qwM2uzou83rkZpSqkMtZ4Ein94KyuDywDXhko2kufPRud9OkAWdw cIxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=fIDvcIp0irJ9nejo79mAMo8eZX7vhyfnB/9sV4I6BVc=; b=0qWogzeT4O0EWznHiKhXFxwF8/QSM0ZmUp/XzZPJ5uPAMvOoVf0N3uIR9wFBCW1J8z E0VJZ42JDns2zMSbXJMOv5OjKpvmu2q8rWQhUAWB6J0fRCkQg1jnUzscDh7crqyzkkiZ 9si6tSugAykyYpIe4ujvUPEjPxzgD2G5IH1Nw9WuO9BfUWLzj/LrzbUr/f2kGSKdoz9Y L/OK2YobkvQfI70NQNlRwU1hDsRWMlFLTfeE1cRfJch72Wp8SJN+JhlImiYspmRLWqVr HiZFDzVhd8VyXc8kEaIPDfBmxw6mDdRLMwec3F0Synuu3sfGM2EV52tkXM8dlLtDZ7ik THsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=UZV+c3hi; dkim=neutral (no key) header.i=@suse.cz header.b=dQGIBY9s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v8-20020aa799c8000000b00640ee8ddf24si3737832pfi.87.2023.05.06.00.57.23; Sat, 06 May 2023 00:57:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=UZV+c3hi; dkim=neutral (no key) header.i=@suse.cz header.b=dQGIBY9s; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231557AbjEFHo4 (ORCPT + 99 others); Sat, 6 May 2023 03:44:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231444AbjEFHoy (ORCPT ); Sat, 6 May 2023 03:44:54 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3551E46; Sat, 6 May 2023 00:44:52 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 5B82A22316; Sat, 6 May 2023 07:44:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1683359091; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fIDvcIp0irJ9nejo79mAMo8eZX7vhyfnB/9sV4I6BVc=; b=UZV+c3hiyyOkfV/XezlgAfmyyo/QUMnJEhP4WzWXfiaKANzoCNt5LA/dQb5h/oPNdB+r0r 0+6pGoMUr5MZYrNQL4dHdFXmTco0B5rROt1idt3GO+qquSE4iH/ByLsUIbjKHjlIMmJ27m rjTkGLuTXK8Zg03go7YkM99O+IvuUiY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1683359091; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fIDvcIp0irJ9nejo79mAMo8eZX7vhyfnB/9sV4I6BVc=; b=dQGIBY9s2MYs2o/JzZcBaikk819IihoO+S/GdXDCBW824SyAsNLgrFKK+HdzfcAnGbZOBO OR27gVT3dPS8+WCg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 0C252134FB; Sat, 6 May 2023 07:44:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id KSY+AnMFVmRHXgAAMHmgww (envelope-from ); Sat, 06 May 2023 07:44:51 +0000 Message-ID: <3b0ec3da-ba18-7b9f-4e84-1cc30e78aed7@suse.cz> Date: Sat, 6 May 2023 09:44:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) To: David Hildenbrand , Jarkko Sakkinen , Sean Christopherson , Chao Peng Cc: Paolo Bonzini , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , "Maciej S . Szmigiero" , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , wei.w.wang@intel.com, Mike Rapoport , Liam Merwick , Isaku Yamahata , Ackerley Tng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <658018f9-581c-7786-795a-85227c712be0@redhat.com> <6db68140-0612-a7a3-2cec-c583b2ed3a61@redhat.com> Content-Language: en-US From: Vlastimil Babka In-Reply-To: <6db68140-0612-a7a3-2cec-c583b2ed3a61@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/5/23 22:00, David Hildenbrand wrote: > On 23.04.23 15:28, Jarkko Sakkinen wrote: >> 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 >>> does look/sound less horrible. >>> >>>> >>>> I want to start referring to the code/patches by its syscall/implementation name >>>> instead of "UPM", as "UPM" is (a) very KVM centric, (b) refers to the broader effort >>>> and not just the non-KVM code, and (c) will likely be confusing for future reviewers >>>> since there's nothing in the code that mentions "UPM" in any way. >>>> >>>> But typing out restrictedmem is quite tedious, and git grep shows that "rmem" is >>>> already used to refer to "reserved memory". >>>> >>>> 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. > > I was also thinking along the lines of isolated_mem or imem ... > essentially, isolated from (unprivileged) user space. > > ... if we still want to have a common syscall for it. I'm fan of the ioctl, if it has a chance of working out.