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 6B7C3C77B75 for ; Tue, 18 Apr 2023 08:54:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231143AbjDRIyn (ORCPT ); Tue, 18 Apr 2023 04:54:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229884AbjDRIyj (ORCPT ); Tue, 18 Apr 2023 04:54:39 -0400 Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 950F56591 for ; Tue, 18 Apr 2023 01:54:36 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id a10so12761792ljr.5 for ; Tue, 18 Apr 2023 01:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681808075; x=1684400075; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xMHN7KanUjqen8e6uVmp37kumpsKyjGdw6AOhbW3UBU=; b=0/NlYDx4EiWln6WGkyAM+LND7xNxWwQqqHb0Bagd4elMu3Fv5oW/J6WzKrzblGLgjg QBCRSsT1QsjFJ5LpTceQNsUjSIW/vYv4IsUI0ic3ecs4n46TAZrNdbpbP2Ae30c4qR0p 1fgyohj177jjxFtXnbNjDtstSv19CzZqZZSBGw4LkSSOrt9u8BxODcNE/Kn5BxhdG+sQ qJiZXN+TLwWFx2byQR6OGeQ0p+PRhHH+Yo30+PGPl5VrUdyJxe4581ktRMnIHc0pz4bo w//7wMblOyDCgzc7zxTO+DS592hnbam0wNDEdEI9KWoPgbzvkjMe+7jSDks2pSsdDrE+ +grw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681808075; x=1684400075; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xMHN7KanUjqen8e6uVmp37kumpsKyjGdw6AOhbW3UBU=; b=ZFoR4vVjSPE59GDoAuH7mj03wWxvmq/cDNuWmet9NicAQNpISJgykV6KkN56PvzhCp 6hPhJa15LG49F1CEPs1QSpNl+1wMwy8fkmy6w+DwIRFa+mn6YMkofYG+eJZG0iAXNNy2 dTJoY6GrBpzLQNt0E7iHn0NE10ZUR2v1YSO91TOPFBeLUe5d1qYhgpiRNoPkp9DAsGQr SrWQ7Z84+36Mqf0sjKflTL6XPUmHEHpQs8nF7azoeHtjcFiUIIk2DowBV6OXjHkdgPdH GtTt+J3CthhevWN++kRa5VLRrHay6n56RpGv/FvZ4NsP+CrDMpWpPr6+DWZHj8EiI5S1 vwZg== X-Gm-Message-State: AAQBX9cPHciKHaRW/v5wqTLq9mk3SJtL2y6/Hcpdm+VnECemoLmwrmpS dgg4S9AtqmgeFYZppjJly0mKDwC0kjqG18R1qk6Ytg== X-Google-Smtp-Source: AKy350bCEQalP/fbiKvcBmlr9tbLu3erHEDBPXKGWUTTRp3BIS6TnglUBHvT6cs+homarGk2KDPMzM/F3Nhr/3LYUsk= X-Received: by 2002:a05:651c:1a0b:b0:2a8:647b:3024 with SMTP id by11-20020a05651c1a0b00b002a8647b3024mr463620ljb.25.1681808074745; Tue, 18 Apr 2023 01:54:34 -0700 (PDT) MIME-Version: 1.0 References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <658018f9-581c-7786-795a-85227c712be0@redhat.com> <1ed06a62-05a1-ebe6-7ac4-5b35ba272d13@redhat.com> In-Reply-To: From: Fuad Tabba Date: Tue, 18 Apr 2023 09:53:58 +0100 Message-ID: Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM) To: Sean Christopherson Cc: David Hildenbrand , Chao Peng , Paolo Bonzini , Vitaly Kuznetsov , Jim Mattson , Joerg Roedel , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , dhildenb@redhat.com, Quentin Perret , Michael Roth , wei.w.wang@intel.com, Mike Rapoport , Liam Merwick , Isaku Yamahata , Jarkko Sakkinen , Ackerley Tng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 17, 2023 at 8:16=E2=80=AFPM Sean Christopherson wrote: .... > > So the fd content is inaccessible using the ordinary POSIX syscalls. It= 's > > only accessible by special entities (e.g., KVM). > > > > Most probably I am forgetting something. But maybe that will help to fi= nd a > > more expressive name. Maybe :) > > Hidden/Concealed/etc - Too close to secretmem, suffers the "hidden from w= hom" problem, > and depending on the use case, the memory may not actually be concealed f= rom the > user that controls the VMM. > > Restricted - "rmem" collides with "reserved memory" in code. > > Guarded - Conflicts with s390's "guarded storage", has the "from whom" pr= oblem. > > Inaccessible - Many of the same problems as "hidden". > > Unmappable - Doesn't cover things like read/write, and is wrong in the se= nse that > the memory is still mappable, just not via mmap(). > > Secured - I'm not getting anywhere near this one :-) How about "protected" ;)? _ducks_ To me the name doesn't matter much, but fwiw I have developed a liking to "restricted", more than the previous "private", since of all of the one-word suggestions I think it captures most of what it's trying to do. Cheers, /fuad