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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67746C433FE for ; Thu, 3 Nov 2022 23:10:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B40FD6B0072; Thu, 3 Nov 2022 19:10:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF0A26B0073; Thu, 3 Nov 2022 19:10:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B8646B0074; Thu, 3 Nov 2022 19:10:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8C0426B0072 for ; Thu, 3 Nov 2022 19:10:30 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4D169ABF80 for ; Thu, 3 Nov 2022 23:10:30 +0000 (UTC) X-FDA: 80093677020.30.75179FF Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf22.hostedemail.com (Postfix) with ESMTP id E025DC0002 for ; Thu, 3 Nov 2022 23:10:29 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id e15so2179935qvo.4 for ; Thu, 03 Nov 2022 16:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Ty7NKEPl0IHHIKXvP+jXCaEpuJOC+fqTvmEMtCpQ/20=; b=rQnp+SwB2zMSq0CxGruqys/HkI4BO0cs24vZcUtuIOAevup3Y78FQIob1VLtYPM4TW cAdQKut1sAQnbM6RE4Nm9dOd/n1bzcGOEZ2ElA8ACLK+5DrOk66Qd9UjphJMHGodCVhB suednwHwQu0747FO0ErJ6MskTw3c1IHuy97x4qT7qRTobrAjI2qqaQ9qrsYHObDuiLne 9nFHuZfBYQuomcslj83mRerOA09HO4FMwWxhwjluEXAf5450VKKTvi3I6AJxRsOgPMbS 0iZx3Y49cYnH4f0Dk4p0nvsEgI5F5O70XswxtMhuqEnZHAoYkQNfeej4jHze5fR+sQEe eEWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ty7NKEPl0IHHIKXvP+jXCaEpuJOC+fqTvmEMtCpQ/20=; b=XkmxA6QdATsCDqJJLoGnZ7JcQyQBfK9YCyzZghNEWguqOtTTm8usBM1PjcrmLkDEWb PqBT2sdZ9E3yZ8G7CoKuF7Gq15Hb9kLNx3Ry75NO8uLX/ANYS8umXDwGp805iWo8XBM0 asFWQ+acZ1PmjN/pBAEjNvvSEi1mgB0W2ziki7bS447YRhteFQaRWhnHmaQ0av7JtpQD ++HOvOhawsxBc8b+eqBoJL97j86iTRGqDCUMUGVdUh8sCzDfVRu3XRsW4SsoulujyJgK iQEF3sxWFy4IJg3sLuLCXnGsV4DwL6NKEDffN53mT/wrvhIDYNgPEwljNIzpi18X3Lew Lk/Q== X-Gm-Message-State: ACrzQf1tw52Vrz7bPgDcHIt3lMk3taupp421DeCu0ZETtctJPO3ejpHy w18nvBPjOTn4s+kiY6WDaGLdN1/dykY9ww== X-Google-Smtp-Source: AMsMyM4SAC4AWjYSYyCN4S3X8KC1TnM1iyPSaM02SstCPPdhS3uGTSJeL2KSiB26C81hZIhFnQ7kZg== X-Received: by 2002:a17:902:d4ce:b0:188:5340:4a3a with SMTP id o14-20020a170902d4ce00b0018853404a3amr5770987plg.79.1667516698820; Thu, 03 Nov 2022 16:04:58 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id x12-20020a62860c000000b0056281da3bcbsm1297475pfd.149.2022.11.03.16.04.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Nov 2022 16:04:57 -0700 (PDT) Date: Thu, 3 Nov 2022 23:04:53 +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-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.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 , tabba@google.com, Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 5/8] KVM: Register/unregister the guest private memory regions Message-ID: References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-6-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221025151344.3784230-6-chao.p.peng@linux.intel.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667517029; a=rsa-sha256; cv=none; b=qZ3VElYmlKiU+mI6mFbnYaAj2VuEl9tZOOnxyJoAv/Dduap9UncYDKdcXVglvpnsiF5yBB FaWYvuIfcGtauuBANh+oZsko620+htNqirm9hXkPEbt9e46Kh5Eu8Y8LeSavsRegiBr6KR jkRYV763/kCQEESdTd7jRs4ZOqZUsCk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rQnp+SwB; spf=pass (imf22.hostedemail.com: domain of seanjc@google.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667517029; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Ty7NKEPl0IHHIKXvP+jXCaEpuJOC+fqTvmEMtCpQ/20=; b=AGB/v1BUZWtRZ0uGzfPp6eCQhX/XTwVvfqxRvDzfiY84VYDx1g+T+fIA7FksrWxp5XPQIR 04s1WfvBQSwUB2NQDu5KH2NBkP6dSRCJXel5KKiVtrB2t7BbTTTHTZqiWpO0gbNjAqkfH/ +pu1vAFd3y9q0BSFGIn6TDr+TymayR4= X-Stat-Signature: ajcr4nop6489ztunyt4emaynn3u7tirc X-Rspamd-Server: rspam09 X-Rspam-User: X-Rspamd-Queue-Id: E025DC0002 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rQnp+SwB; spf=pass (imf22.hostedemail.com: domain of seanjc@google.com designates 209.85.219.46 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1667517029-137881 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 25, 2022, Chao Peng wrote: > @@ -4708,6 +4802,24 @@ static long kvm_vm_ioctl(struct file *filp, > r = kvm_vm_ioctl_set_memory_region(kvm, &mem); > break; > } > +#ifdef CONFIG_KVM_GENERIC_PRIVATE_MEM > + case KVM_MEMORY_ENCRYPT_REG_REGION: > + case KVM_MEMORY_ENCRYPT_UNREG_REGION: { I'm having second thoughts about usurping KVM_MEMORY_ENCRYPT_(UN)REG_REGION. Aside from the fact that restricted/protected memory may not be encrypted, there are other potential use cases for per-page memory attributes[*], e.g. to make memory read-only (or no-exec, or exec-only, etc...) without having to modify memslots. Any paravirt use case where the attributes of a page are effectively dictated by the guest is going to run into the exact same performance problems with memslots, which isn't suprising in hindsight since shared vs. private is really just an attribute, albeit with extra special semantics. And if we go with a brand new ioctl(), maybe someday in the very distant future we can deprecate and delete KVM_MEMORY_ENCRYPT_(UN)REG_REGION. Switching to a new ioctl() should be a minor change, i.e. shouldn't throw too big of a wrench into things. Something like: KVM_SET_MEMORY_ATTRIBUTES struct kvm_memory_attributes { __u64 address; __u64 size; __u64 flags; } [*] https://lore.kernel.org/all/Y1a1i9vbJ%2FpVmV9r@google.com > + struct kvm_enc_region region; > + bool set = ioctl == KVM_MEMORY_ENCRYPT_REG_REGION; > + > + if (!kvm_arch_has_private_mem(kvm)) > + goto arch_vm_ioctl; > + > + r = -EFAULT; > + if (copy_from_user(®ion, argp, sizeof(region))) > + goto out; > + > + r = kvm_vm_ioctl_set_mem_attr(kvm, region.addr, > + region.size, set); > + break; > + } > +#endif