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 D5F2BCCA480 for ; Wed, 20 Jul 2022 16:44:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233310AbiGTQoj (ORCPT ); Wed, 20 Jul 2022 12:44:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232173AbiGTQoj (ORCPT ); Wed, 20 Jul 2022 12:44:39 -0400 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65B9065D7D for ; Wed, 20 Jul 2022 09:44:37 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so2802065pjf.2 for ; Wed, 20 Jul 2022 09:44:37 -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=NKI6wQLzSjuIgXqGP/STBDd/io3ztt1cS6FImLHwFp4=; b=aYf105zHRqcKnwIvd6ekmpqruUyQToVuka3h99YqNWRmFXkZ7ZVHV8oWNskzAvMx2F hflOC9nxBStxjqtxvcltphe6Q5E58yJ1G2iJfhXNEqLsdIUxBz1Jghs5U/OLu3mGUc1a JRrnyPRUFOER4kSZYOrYSqnkSlzR3XQAIIqK13/lyE2A23HrMPyXlZiOV822mKgY0tgd nTwYcdRpttHY+A4wo2bLHxYVFSJL0sIrCNfPF0RyUS+KwJ64AABEJ8yX01Hb9NjXpaI/ s6Pf48SWnWTxK6vMsYlo9rnJGzIsPUCTu5j+IdeVl1yrYnYpbPzLMaw748Y0j9AcRKUU ZGfw== 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=NKI6wQLzSjuIgXqGP/STBDd/io3ztt1cS6FImLHwFp4=; b=inS0DVmsxbg4hbJrCFUkUJMV58rIF0GVy/XARcHwy1TEoVJV3URHLAyCmJuaz3kdgz xgaiTAf2jGG6cNqzMCwWh10q+lvtjzUZxddcCO9D/Qflqqa4zBN8DYWKOWZnFl/T5Ovb 3sAkV2TN59rP2hHiLcAMfQyo27HafHScIqG5sAg80hVKHu0hn/BS8NE7HVHniYYAVY08 lP6BBdln+ieycuxAKlFBEo0m28VocPfDLP/jhwD/tehlg+8YGDVhbQKI2ENWpIUcE2Oi yGEAFsBuUBFgy8cAwL9kNUgMvUggew2LBSvaSPlmvAfZV5i4gOZ0tAfW3Q1cJvG9yUlS Dayg== X-Gm-Message-State: AJIora+wBvrwz5rbfznpnv4Q7xu8jyQR5j7n//mJXN2FScMGKX3gkji/ 3JUO+p6vLIjiIdVo+6iiFLqQhQ== X-Google-Smtp-Source: AGRyM1utYrsQFWglg8OIUvJRKtR6LVkU7MbzTy7HM7RFQtBExxPfhBWR/u5swtl61L63cUwi4vupQg== X-Received: by 2002:a17:90b:3ec1:b0:1f1:edcf:dd2b with SMTP id rm1-20020a17090b3ec100b001f1edcfdd2bmr6535996pjb.156.1658335476747; Wed, 20 Jul 2022 09:44:36 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id k6-20020aa79986000000b00528c22038f5sm14345128pfh.14.2022.07.20.09.44.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 09:44:36 -0700 (PDT) Date: Wed, 20 Jul 2022 16:44:32 +0000 From: Sean Christopherson To: Chao Peng Cc: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220706082016.2603916-12-chao.p.peng@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Wed, Jul 06, 2022, Chao Peng wrote: > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 230c8ff9659c..bb714c2a4b06 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -914,6 +914,35 @@ static int kvm_init_mmu_notifier(struct kvm *kvm) > > #endif /* CONFIG_MMU_NOTIFIER && KVM_ARCH_WANT_MMU_NOTIFIER */ > > +#ifdef CONFIG_HAVE_KVM_PRIVATE_MEM > +#define KVM_MEM_ATTR_PRIVATE 0x0001 > +static int kvm_vm_ioctl_set_encrypted_region(struct kvm *kvm, unsigned int ioctl, > + struct kvm_enc_region *region) > +{ > + unsigned long start, end; As alluded to in a different reply, because this will track GPAs instead of HVAs, the type needs to be "gpa_t", not "unsigned long". Oh, actually, they need to be gfn_t, since those are what gets shoved into the xarray. > + void *entry; > + int r; > + > + if (region->size == 0 || region->addr + region->size < region->addr) > + return -EINVAL; > + if (region->addr & (PAGE_SIZE - 1) || region->size & (PAGE_SIZE - 1)) > + return -EINVAL; > + > + start = region->addr >> PAGE_SHIFT; > + end = (region->addr + region->size - 1) >> PAGE_SHIFT; > + > + entry = ioctl == KVM_MEMORY_ENCRYPT_REG_REGION ? > + xa_mk_value(KVM_MEM_ATTR_PRIVATE) : NULL; > + > + r = xa_err(xa_store_range(&kvm->mem_attr_array, start, end, > + entry, GFP_KERNEL_ACCOUNT)); IIUC, this series treats memory as shared by default. I think we should invert that and have KVM's ABI be that all guest memory as private by default, i.e. require the guest to opt into sharing memory instead of opt out of sharing memory. And then the xarray would track which regions are shared. Regarding mem_attr_array, it probably makes sense to explicitly include what it's tracking in the name, i.e. name it {private,shared}_mem_array depending on whether it's used to track private vs. shared memory. If we ever need to track metadata beyond shared/private then we can tweak the name as needed, e.g. if hardware ever supports secondary non-ephemeral encryption keys.