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 8C936C6379F for ; Thu, 19 Jan 2023 13:03:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20DE56B0075; Thu, 19 Jan 2023 08:03:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BD056B0078; Thu, 19 Jan 2023 08:03:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 084D16B007B; Thu, 19 Jan 2023 08:03:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ED1646B0075 for ; Thu, 19 Jan 2023 08:03:24 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A33F81205F6 for ; Thu, 19 Jan 2023 13:03:24 +0000 (UTC) X-FDA: 80371564728.19.9F730EF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 068501C0020 for ; Thu, 19 Jan 2023 13:03:22 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RZdMtEEu; spf=pass (imf21.hostedemail.com: domain of jarkko@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674133403; 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=fui1GC9xFgJxW6ICpwBpnGiey6q3DFyoacduWCElMkQ=; b=zQYziOLroLQgtbLabJpgv0CKyv5Vf3TdEDc19PLIE2dQbmOHJhtwGnI6ujY+nbRR7qB0LU 43VPI2x1qwbwDMPwvXFNT6eL9A0NruSLlL8rgxYJMLXKcetkyiidWbRcaH2iaJpm+JJ0L1 jCnH0VwFn/SJLPEwImzgFyxiUeelRco= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RZdMtEEu; spf=pass (imf21.hostedemail.com: domain of jarkko@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674133403; a=rsa-sha256; cv=none; b=yCiwb77dzr294dkPnF+zLca0C7KBjxXo/4c2jaxs1++hcLxOISrTl7gj0xU0hX26Rf8K01 PrC0ymjOC9hFPFkwtsDMGQ9HSKElhUUPAsibpFt2sRtS57olyQVjDIHxWnaFssNxO+F0Kx km+zsMNYo0Ej/deri7okwX5P+HGRGpA= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DD0D560F59; Thu, 19 Jan 2023 13:03:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBB22C433EF; Thu, 19 Jan 2023 13:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674133401; bh=ijfFcGC5kAQ2nYmXEtcyL9+phHOOgiGJvROKRw4V2qo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RZdMtEEuZr7tE97F12rPotBfCByLsKQcgcA6T//IQ5YqeQ/v/D6XDedO0BpuyIUnx TBg5Gnpd4zOJUj/FvJCpx5TpBLL+470yit5tW60gms8xNYxGspnGiJA9tNTbG7R1wv Z1VUxRwnyHcRPmdsKatfbX51tTlsShJvyrmuxG0VDCg1QTDKKpxv0am630By1QBssp vzVOhZKVLz/CJJzpxLSHiCJ2Xa5fGCzVmk3raNpsu/uSz7pax5V9iNKDXGzwIgECbD syk+CFVp5gx0CaFlSgcEdglnzc1pcBa8wCK5SMZItMZeaNCkmFgxHV+fT/JMPsu7eg 1A6DhF3Oj86pQ== Date: Thu, 19 Jan 2023 13:03:17 +0000 From: Jarkko Sakkinen To: Michael Roth Cc: Borislav Petkov , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, ashish.kalra@amd.com, harald@profian.com, chao.p.peng@linux.intel.com Subject: Re: [PATCH RFC v7 02/64] KVM: x86: Add KVM_CAP_UNMAPPED_PRIVATE_MEMORY Message-ID: References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-3-michael.roth@amd.com> <20230104174721.wa4detzppqzvsgsy@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230104174721.wa4detzppqzvsgsy@amd.com> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: ocwaaad6qa443y1esuedpx897br9qt5f X-Rspamd-Queue-Id: 068501C0020 X-HE-Tag: 1674133402-173300 X-HE-Meta: U2FsdGVkX1/tyYKDPV1gAemK1DL6Y3ULVXdj26m92OG7/YFLB/1Cb0/SgMVbgBBjxn+11fcXwYDiBjBF00yufalzLb2trfdgU2ltlqIsWJBk2S5YUXbFeSWaSjszh1qQWbaW7VUHGEjPSYdZ1dR+ZnXJc7AWsnMzIHq5Ze0cJAxJ4iYd3gKq88pxW3Hd3cAl3YLLq3NGlrmPvNC2EQwrWhhUS07kiQ+nKzLOhsP8thWXcwk0KiFBclY8FbIAL3XjQLxxn7jUffBsidlbVK7AEbpUA/VllVvaelMkCBR54Un9z4q8frN1VdBAYoop1O8zMmn2zyY07uKKZEoHcHy+hkM4L68npWAsTW2kjdZKBk2AqKII74a9SQYytRap+lw0NX4waBKJx9F8bBWndNKjhxB2DBOY1n9uLWy92KKoY5EvKncJa7ji5NHNM2uLGlrYCQlmk187+jT6RXOJhF1M3fYT7+OGDRhzeGt42/5W4DWauLGSI4hiZlXvemqlRD5UgAACzhryjNWAsqLqDHm53i8xdcGF/flv7xlFcoBwkQ9VrBaL0iR1XvufbOz5XitVb32ds4pqKslzGOBxaYok5SaEJKGPZ0doZ9/zhueKVMmHlYfYmEvX16Ka/xgaznx0uqXQ4FCP0uePYQkjOM1YLP0AJZmmCDaNi8uMorTrQU3KAXq16RSDQ17LGoKLqzgwi5chxiPNeBFzCQH5TnuJTZG6C/oqu7uWUyTkwf6jqjda7wP89S07EMV0ywYT8RlQP31tiyMPNq9friIzRCegZXp9oe7/cnr+JW7QKf87Ksc/ik2MW6FK8Czw/gYivz+wUvMe9A2yArwrZdRFoNOluLUwki9PDIBW+fY7RvtuqbArziO+pm6s24R/aviB60svvzgfn0HphMb9LZ4EWvmDcdlDDh8GC3gl6teX6AYUnY8CAfqJwzRpMWMCDHGGISPZLuh2w+/SrFocHWmGic0 w4+BwDx0 vk+GzrLcguU4Q0dvmZeQ6B7UVDpsS9rEFrgBFAqGMS1YJ7kY6gzDtwBNrv/iFb/XL530+HndYeEbPZtIi8jKpY0ktHg== 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 Wed, Jan 04, 2023 at 11:47:21AM -0600, Michael Roth wrote: > On Thu, Dec 22, 2022 at 01:26:25PM +0100, Borislav Petkov wrote: > > On Wed, Dec 14, 2022 at 01:39:54PM -0600, Michael Roth wrote: > > > This mainly indicates to KVM that it should expect all private guest > > > memory to be backed by private memslots. Ideally this would work > > > similarly for others archs, give or take a few additional flags, but > > > for now it's a simple boolean indicator for x86. > > > > ... > > > > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > > index c7e9d375a902..cc9424ccf9b2 100644 > > > --- a/include/uapi/linux/kvm.h > > > +++ b/include/uapi/linux/kvm.h > > > @@ -1219,6 +1219,7 @@ struct kvm_ppc_resize_hpt { > > > #define KVM_CAP_DIRTY_LOG_RING_ACQ_REL 223 > > > #define KVM_CAP_S390_PROTECTED_ASYNC_DISABLE 224 > > > #define KVM_CAP_MEMORY_ATTRIBUTES 225 > > > +#define KVM_CAP_UNMAPPED_PRIVATE_MEM 240 > > > > Isn't this new cap supposed to be documented somewhere in > > Documentation/virt/kvm/api.rst ? > > It should, but this is sort of a placeholder for now. Ideally we'd > re-use the capabilities introduced by UPM patchset rather than introduce > a new one. Originally the UPM patchset had a KVM_CAP_PRIVATE_MEM which > we planned to use to switch between legacy SEV and UPM-based SEV (for > lazy-pinning support) by making it writeable, but that was removed in v10 > in favor of KVM_CAP_MEMORY_ATTRIBUTES, which is tied to the new > KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES/KVM_SET_MEMORY_ATTRIBUTES ioctls: > > https://lore.kernel.org/lkml/CA+EHjTxXOdzcP25F57Mtmnb1NWyG5DcyqeDPqzjEOzRUrqH8FQ@mail.gmail.com/ > > It wasn't clear at the time if that was the right interface to use for > this particular case, so we stuck with the more general > 'use-upm/dont-use-upm' semantics originally provided by making > KVM_CAP_UNMAPPED_PRIVATE_MEM/KVM_CAP_PRIVATE_MEM writeable. > > But maybe it's okay to just make KVM_CAP_MEMORY_ATTRIBUTES writeable and > require userspace to negotiate it rather than just tying it to > CONFIG_HAVE_KVM_MEMORY_ATTRIBUTES. Or maybe introducing a new > KVM_SET_SUPPORTED_MEMORY_ATTRIBUTES ioctl to pair with > KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES. It sort of makes sense, since userspace > needs to be prepared to deal with KVM_EXIT_MEMORY_FAULTs relating to these > attributes. Doesn't upm patch set imply that user space should negotiate the memory attributes with the ioctl? For me it looks like that the problem is introduced by conflicting usage pattern in the SNP code [*]. Perhaps sev_launch_update_gfn_handler() should not set memory attributes but instead expect user space to do it before the call? [*] https://lore.kernel.org/all/Y8cydYUfTUFwCh4K@kernel.org/ BR, Jarkko