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 60F52C4332F for ; Mon, 19 Dec 2022 14:36:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3A158E0003; Mon, 19 Dec 2022 09:36:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEA3D8E0001; Mon, 19 Dec 2022 09:36:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB2C38E0003; Mon, 19 Dec 2022 09:36:52 -0500 (EST) 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 CD0158E0001 for ; Mon, 19 Dec 2022 09:36:52 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 62335140A91 for ; Mon, 19 Dec 2022 14:36:52 +0000 (UTC) X-FDA: 80259307464.13.E6E4ABF Received: from mail.skyhub.de (unknown [5.9.137.197]) by imf25.hostedemail.com (Postfix) with ESMTP id BFCCAA0018 for ; Mon, 19 Dec 2022 14:36:44 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=g4O8WnDj; spf=temperror (imf25.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1671460609; 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=Nr0Z4OvkPMBKiUgwrvy1b0JeJ5CuH4u8cdycIbF3VTo=; b=rWOTn4e7ZBBjkjOZTcdl4nSUw7mNKnDYzkNov6tMiazZjAmE63Z4MM1W4znoqP0jlhZQBO UQVSqb6+ujk132EA++2SaPvAxLQdFMI7JQwStQxnHeBXPpIbeBDTSuFjQaL+IZ5gzGal3S vVP1W1B3dZdWnrxyG9NLeIYlMmL7RUw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=g4O8WnDj; spf=temperror (imf25.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1671460609; a=rsa-sha256; cv=none; b=f35ifFbpLr019VTP64EZgpaICrwtsH6cAdkM63S4MpGAoDlwMUx4e+5VKkD8eWgOD1E2jg Vbhlt8Q5h3Y+DNhdMjpeN1In9bO/Z/hjxg/stiFqfe+LRCujw+b21ougqDpluoH29I6ksu aw5uX4jQyCRwOX2/a05L7vWtfn5ihT8= Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id ECC051EC06BD; Mon, 19 Dec 2022 15:36:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1671460593; h=from:from: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; bh=Nr0Z4OvkPMBKiUgwrvy1b0JeJ5CuH4u8cdycIbF3VTo=; b=g4O8WnDjjWmrtbFmMTY4G0yltCqzIeXhWywY3xwLBgdFTN9TCYZMZhAq9By4cTHHjnVkHt 354idtEXaLQwUDtNstFC6rPiAS1iw8va+w5OrbtVNCuvMSntL0hbmQcddYbRIVl0pEcCkP SG+jpLF4Ne/7gzC4KSRDGyQn3EtYD1Q= Date: Mon, 19 Dec 2022 15:36:28 +0100 From: Borislav Petkov 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 , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , 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, wei.w.wang@intel.com Subject: Re: [PATCH v10 3/9] KVM: Extend the memslot to support fd-based private memory Message-ID: References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-4-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20221202061347.1070246-4-chao.p.peng@linux.intel.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BFCCAA0018 X-Rspam-User: X-Stat-Signature: erx1tiqh974jgymj83t1wmrcxsw64ywq X-HE-Tag: 1671460604-785130 X-HE-Meta: U2FsdGVkX18IrroaezCpUJMB+wGp1iGoLBocKU+oY91zGxODtC7mk4arrLYFWn9T2+L2wHcDO0ylBVVYWma5J5Srpma3u9Yn9TiiOj7FMrvAdy2pDdfrMh3NEKM1icRWOJYiHKHbpzCpvyShUeJJtz07rqc7B2aIT5ogvTGibPM2IMLYF3fAw/hfUJT6CUdlNMIcZ9quZB0bAHaKm6nxl5N3dr9Cpd3gFi8or23k+sQJEFUOY5AGBdyVk9VElvyHzvxkSIb0HvEvQTRx2HBbe0+1awkZEiCoLNa99h9+TX0EJ40GEWVnS9tNGwjmRKp8kBzo/lngVMB5qRlCuNio70rjirGu8RQpclHaLXuUGltqwrJsxVfY3VFjwSqf0rLTddKjD0GTQgifDmi2XO/EwNX7CJJoDIamBkRWmXSMYgbdjxhr+3dzz0PH04qS/QjLYFw8OBGObT7ie6zFu/D9+8KOT3hnVN/Ss5lTu80SQAN55jrHSfj0eQnuWMsOzfSbnEjmGBwUOH8nr9WD0ixj5O8g6oQpznzd/UeePaPGY6a006HAk8QFsZRkxK2aO5gnDZ4DN5SzJYQBBmMJshcmwOVUTPtLfJUDi7ZMaoi5Y+VI4e/iMnudN7HJmMhaVu+Qjvs0FXY55gs2ET3gZZERShsUErrbDNQcF24JDxAMjZh/p4tzYT4Rg7EZT1weFOhiEvgiKSItSnJ5+ueZi2RmJtcS40Sqm07txSufzkN9+95+Xhysz0Y2d9gSFJHiFT1jBtmNtqc2gP7Ph74KbFYyRjFpBu1s4fvEzClNKOD2KJXYkgoCyk9IJglwXVKJH+uBe54J30fLk/x0jTtaKCkpHxThL1JoeE5un640MWATm7umSrwnxJUUlssKyilgg4CV9TYXdmkbjg1tFuNTbppgsbPtm+Vr6GF8UtNXqrPpAgcXhnNvliPXy9Lkcb+fq+nj7TfCsMcfK08m7MpJHKX 5z5EKT+E rwFxfFqQBplA3PDk3OKmrS51yZ/sfIQzyj8VDF3PAPBTGEJ2+SvTmTSfCzmPU1X2q1srz5fwT3p5C8Dm1hSaYbth5hoHs2qwtVxDBMzHlZShojicIomVdqbWgHrVtfcyYQbgiuwFUvpjCE+WkKCkXT3+HhZwVT/3DBDcp 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 Fri, Dec 02, 2022 at 02:13:41PM +0800, Chao Peng wrote: > In memory encryption usage, guest memory may be encrypted with special > key and can be accessed only by the guest itself. We call such memory > private memory. It's valueless and sometimes can cause problem to allow valueless? I can't parse that. > userspace to access guest private memory. This new KVM memslot extension > allows guest private memory being provided through a restrictedmem > backed file descriptor(fd) and userspace is restricted to access the > bookmarked memory in the fd. bookmarked? > This new extension, indicated by the new flag KVM_MEM_PRIVATE, adds two > additional KVM memslot fields restricted_fd/restricted_offset to allow > userspace to instruct KVM to provide guest memory through restricted_fd. > 'guest_phys_addr' is mapped at the restricted_offset of restricted_fd > and the size is 'memory_size'. > > The extended memslot can still have the userspace_addr(hva). When use, a "When un use, ..." ... > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > index a8e379a3afee..690cb21010e7 100644 > --- a/arch/x86/kvm/Kconfig > +++ b/arch/x86/kvm/Kconfig > @@ -50,6 +50,8 @@ config KVM > select INTERVAL_TREE > select HAVE_KVM_PM_NOTIFIER if PM > select HAVE_KVM_MEMORY_ATTRIBUTES > + select HAVE_KVM_RESTRICTED_MEM if X86_64 > + select RESTRICTEDMEM if HAVE_KVM_RESTRICTED_MEM Those deps here look weird. RESTRICTEDMEM should be selected by TDX_GUEST as it can't live without it. Then you don't have to select HAVE_KVM_RESTRICTED_MEM simply because of X86_64 - you need that functionality when the respective guest support is enabled in KVM. Then, looking forward into your patchset, I'm not sure you even need HAVE_KVM_RESTRICTED_MEM - you could make it all depend on CONFIG_RESTRICTEDMEM. But that's KVM folks call - I'd always aim for less Kconfig items because we have waay too many. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette