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 BBAD6C43334 for ; Thu, 21 Jul 2022 17:59:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229776AbiGUR7A (ORCPT ); Thu, 21 Jul 2022 13:59:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232006AbiGUR66 (ORCPT ); Thu, 21 Jul 2022 13:58:58 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EC088B490 for ; Thu, 21 Jul 2022 10:58:56 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id b7-20020a17090a12c700b001f20eb82a08so5982909pjg.3 for ; Thu, 21 Jul 2022 10:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wvI0q5HAql8tMPxcnKbiOi/9NxgmmSwnzAAkVZd1GZE=; b=QeJXriKT9c5kzVC7WwOIhi80ckWM6ug8VcaWprkpELe4t4pSILpTjfg8m+cMtOrWBe jmelByXoDseFjzPN05HlM35WJraOgVD8XBmkQsrB5vGpNrj70IhxBhsBNPglHsEpzekf 1kG3W212r4FUnxp6h1itgEO/FJ4Uuo3CeYYXkoiOWqCRXrzKR28+BcJbG5kguyytRjkg rjsFU2rMHcaFZYM7jRBwDx3y4TNjRz8cS5RWMgjh+1ofnV6wnx05hcN9heFlTTNfsAVq qUjZMJxGLa9mHYyEFjkrcwiRRdLtgvROz3H/Z1mIRgvYivxLAzSanUXyi85+4NTaGuJS Ssew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wvI0q5HAql8tMPxcnKbiOi/9NxgmmSwnzAAkVZd1GZE=; b=tGclnO4wleOMpVAqv4IzuMA+5vF+tT4t2lnoO25GgOtu9YeX52/bEtKyTuZ3uOKmOo HTqcglm+yxgr2qsbCBzwCymNcAw2tXw32u36CAVfWicUI6JKAZBIkgUeI3bDQH2wl+h7 5dLCSlb9TY37fepuED9RCR99Y8dgwihMSDHiT4gpD7foPTUlBMjE0BN8RKtKthN+m2+D BqUlLd/jEwHqxqlgcOtRjU3uy4ImbUeJphbY5rTFZu2011o6ieZo1cybT9QzRiW4r2iv 3F7QT3JaSDnzlFWKgfuOCAIQMu/ZScXGs6tJRTVb6AXZNcRZJLBi1UJmsiAIEns2vvZf gUYg== X-Gm-Message-State: AJIora+fN2vnPmJzpR0Mi3mtPbqzZDvnvxHj8WDzv/DglhgzJeJZmDhT pbn297CZBPq1SR9sTkbDzm85Qw== X-Google-Smtp-Source: AGRyM1sy1sNPIZTfbcs9D/R5onBZFJSx4EAG07fQgd3u5pHjtvT3tSBi6UiM7uRquYtBlR+3qYzZvg== X-Received: by 2002:a17:90b:3d84:b0:1ef:9049:9f43 with SMTP id pq4-20020a17090b3d8400b001ef90499f43mr12682443pjb.45.1658426335405; Thu, 21 Jul 2022 10:58:55 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id f4-20020a170902684400b0016c1cdd2de3sm1956763pln.281.2022.07.21.10.58.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 10:58:54 -0700 (PDT) Date: Thu, 21 Jul 2022 17:58:50 +0000 From: Sean Christopherson To: Chao Peng Cc: Wei Wang , "Gupta, Pankaj" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song Subject: Re: [PATCH v7 11/14] KVM: Register/unregister the guest private memory regions Message-ID: References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-12-chao.p.peng@linux.intel.com> <20220719140843.GA84779@chaop.bj.intel.com> <36e671d2-6b95-8e4f-c2ac-fee4b2670c6e@amd.com> <20220720150706.GB124133@chaop.bj.intel.com> <45ae9f57-d595-f202-abb5-26a03a2ca131@linux.intel.com> <20220721092906.GA153288@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220721092906.GA153288@chaop.bj.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 21, 2022, Chao Peng wrote: > On Thu, Jul 21, 2022 at 03:34:59PM +0800, Wei Wang wrote: > > > > > > On 7/21/22 00:21, Sean Christopherson wrote: > > Maybe you could tag it with cgs for all the confidential guest support > > related stuff: e.g. kvm_vm_ioctl_set_cgs_mem() > > > > bool is_private = ioctl == KVM_MEMORY_ENCRYPT_REG_REGION; > > ... > > kvm_vm_ioctl_set_cgs_mem(, is_private) > > If we plan to widely use such abbr. through KVM (e.g. it's well known), > I'm fine. I'd prefer to stay away from "confidential guest", and away from any VM-scoped name for that matter. User-unmappable memmory has use cases beyond hiding guest state from the host, e.g. userspace could use inaccessible/unmappable memory to harden itself against unintentional access to guest memory. > I actually use mem_attr in patch: https://lkml.org/lkml/2022/7/20/610 > But I also don't quite like it, it's so generic and sounds say nothing. > > But I do want a name can cover future usages other than just > private/shared (pKVM for example may have a third state). I don't think there can be a third top-level state. Memory is either private to the guest or it's not. There can be sub-states, e.g. memory could be selectively shared or encrypted with a different key, in which case we'd need metadata to track that state. Though that begs the question of whether or not private_fd is the correct terminology. E.g. if guest memory is backed by a memfd that can't be mapped by userspace (currently F_SEAL_INACCESSIBLE), but something else in the kernel plugs that memory into a device or another VM, then arguably that memory is shared, especially the multi-VM scenario. For TDX and SNP "private vs. shared" is likely the correct terminology given the current specs, but for generic KVM it's probably better to align with whatever terminology is used for memfd. "inaccessible_fd" and "user_inaccessible_fd" are a bit odd since the fd itself is accesible. What about "user_unmappable"? E.g. F_SEAL_USER_UNMAPPABLE, MFD_USER_UNMAPPABLE, KVM_HAS_USER_UNMAPPABLE_MEMORY, MEMFILE_F_USER_INACCESSIBLE, user_unmappable_fd, etc... that gives us flexibility to map the memory from within the kernel, e.g. into other VMs or devices. Hmm, and then keep your original "mem_attr_array" name? And probably int kvm_vm_ioctl_set_mem_attr(struct kvm *kvm, gpa_t gpa, gpa_t size, bool is_user_mappable) Then the x86/mmu code for TDX/SNP private faults could be: is_private = !kvm_is_gpa_user_mappable(); if (fault->is_private != is_private) { or if we want to avoid mixing up "user_mappable" and "user_unmappable": is_private = kvm_is_gpa_user_unmappable(); if (fault->is_private != is_private) { though a helper that returns a negative (not mappable) feels kludgy. And I like kvm_is_gpa_user_mappable() because then when there's not "special" memory, it defaults to true, which is more intuitive IMO. And then if the future needs more precision, e.g. user-unmappable memory isn't necessarily guest-exclusive, the uAPI names still work even though KVM internals will need to be reworked, but that's unavoidable. E.g. piggybacking KVM_MEMORY_ENCRYPT_(UN)REG_REGION doesn't allow for further differentiation, so we'd need to _extend_ the uAPI, but the _existing_ uAPI would still be sane.