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 2D4AEC4332F for ; Wed, 16 Nov 2022 18:16:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D7166B0072; Wed, 16 Nov 2022 13:16:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7604A6B0073; Wed, 16 Nov 2022 13:16:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DA0A6B0074; Wed, 16 Nov 2022 13:16:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4A4B86B0072 for ; Wed, 16 Nov 2022 13:16:14 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1426712017E for ; Wed, 16 Nov 2022 18:16:14 +0000 (UTC) X-FDA: 80140109868.28.E09C477 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf25.hostedemail.com (Postfix) with ESMTP id 5FE5BA0011 for ; Wed, 16 Nov 2022 18:16:13 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id 3D7A5B81E1A; Wed, 16 Nov 2022 18:16:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DD2FC433C1; Wed, 16 Nov 2022 18:16:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668622569; bh=HzuBDu3c95vDubumkqmlUpDyU7sgxHKyh2YYcB7elbo=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=TbmnRT02WifHTxhTrt1S3QFCyS10+Ny8syMNvxDvCWtyKPfr7LxVjdR8fA+mn6x8K TsqHlf93e0eTek76c8sWRQJ/Q0wTsu7zLYhedhBDN+ZnKJEJv5cvOf4FfQn8h0fvl4 /jjXz3QpsD70FN6lVPept8h//e/SZAqJlXfr+BkgivEFfgUDYnlO34jr+hOieTfrxk t+EXIu5KUxj69jixwFESCcWu726SGo8juE7CfEqbzz6Pu9Xl21jTZ6gR1r4345b1eQ VwMnJ+2Is2wAe2rHopq09K1eS+AVjQRkSa87F6KrzUaYFz9TTDZmv22MRmAFfWJwzM jOh2TpPLVa4LA== Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 6393627C0054; Wed, 16 Nov 2022 13:16:07 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Wed, 16 Nov 2022 13:16:07 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgeeigdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepgedugedtledtieduteffveevhfefheeuhfegfeduvdeltdeugeet veeliedvfeehnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhguhidomhgvshhmthhprghu thhhphgvrhhsohhnrghlihhthidqudduiedukeehieefvddqvdeifeduieeitdekqdhluh htoheppehkvghrnhgvlhdrohhrgheslhhinhhugidrlhhuthhordhush X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4E7E831A0063; Wed, 16 Nov 2022 13:16:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: <2e252f4f-7d45-42ac-a88f-fa8045fe3748@app.fastmail.com> In-Reply-To: <20221025151344.3784230-4-chao.p.peng@linux.intel.com> References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-4-chao.p.peng@linux.intel.com> Date: Wed, 16 Nov 2022 10:15:44 -0800 From: "Andy Lutomirski" To: "Chao Peng" , "kvm list" , "Linux Kernel Mailing List" , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, "Linux API" , linux-doc@vger.kernel.org, qemu-devel@nongnu.org Cc: "Paolo Bonzini" , "Jonathan Corbet" , "Sean Christopherson" , "Vitaly Kuznetsov" , "Wanpeng Li" , "Jim Mattson" , "Joerg Roedel" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "the arch/x86 maintainers" , "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" , "Nakajima, Jun" , "Dave Hansen" , "Andi Kleen" , "David Hildenbrand" , aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, "Quentin Perret" , "Fuad Tabba" , "Michael Roth" , "Michal Hocko" , "Muchun Song" , "Wei W Wang" Subject: Re: [PATCH v9 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit Content-Type: text/plain ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668622573; a=rsa-sha256; cv=none; b=L/htUBiJkxH4bNyXi/ej5o66V1VqFfMYWmyDXaBoGfMyuVTUKCesMSowEP4uoE08/HyW9w aoezBiEnRafejYnfj7cTyqoWOjolMvd+nURmuvLFvs1flMAaMJMQFphLJwqL1yaVaEfuzN Njy8rX052IV6gIq3wzQEutHRedExDAI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TbmnRT02; spf=pass (imf25.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@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=1668622573; 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=b5dTEfUA5K9hb7HFOsVJe59yS6OLXbe1GvgWoyoKR/4=; b=kElQTpNe3tizG9zGuoGfzClU0xGPZALg247TI4FqMCmmr3f3m3ucJKoXfePCbWrERk3PNp rqpR6itaB5qdGEAzD0VCHKC08SiEJBokGPI7/Ysxrvve8hDGIyXplpEYQxCmGloV2Huo6d BglfZuUZN6mScPFeMxE3/S8OUwLkIZ4= X-Stat-Signature: 6qzucjy37gwt95q3z5h64sftz6okekaq X-Rspamd-Queue-Id: 5FE5BA0011 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TbmnRT02; spf=pass (imf25.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1668622573-302128 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, at 8:13 AM, Chao Peng wrote: > This new KVM exit allows userspace to handle memory-related errors. It > indicates an error happens in KVM at guest memory range [gpa, gpa+size). > The flags includes additional information for userspace to handle the > error. Currently bit 0 is defined as 'private memory' where '1' > indicates error happens due to private memory access and '0' indicates > error happens due to shared memory access. > > When private memory is enabled, this new exit will be used for KVM to > exit to userspace for shared <-> private memory conversion in memory > encryption usage. In such usage, typically there are two kind of memory > conversions: > - explicit conversion: happens when guest explicitly calls into KVM > to map a range (as private or shared), KVM then exits to userspace > to perform the map/unmap operations. > - implicit conversion: happens in KVM page fault handler where KVM > exits to userspace for an implicit conversion when the page is in a > different state than requested (private or shared). > > Suggested-by: Sean Christopherson > Co-developed-by: Yu Zhang > Signed-off-by: Yu Zhang > Signed-off-by: Chao Peng > --- > Documentation/virt/kvm/api.rst | 23 +++++++++++++++++++++++ > include/uapi/linux/kvm.h | 9 +++++++++ > 2 files changed, 32 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst > b/Documentation/virt/kvm/api.rst > index f3fa75649a78..975688912b8c 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6537,6 +6537,29 @@ array field represents return values. The > userspace should update the return > values of SBI call before resuming the VCPU. For more details on > RISC-V SBI > spec refer, https://github.com/riscv/riscv-sbi-doc. > > +:: > + > + /* KVM_EXIT_MEMORY_FAULT */ > + struct { > + #define KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 0) > + __u32 flags; > + __u32 padding; > + __u64 gpa; > + __u64 size; > + } memory; > + Would it make sense to also have a field for the access type (read, write, execute, etc)? I realize that shared <-> private conversion doesn't strictly need this, but it seems like it could be useful for logging failures and also for avoiding a second immediate fault if the type gets converted but doesn't have the right protection yet. (Obviously, if this were changed, KVM would need the ability to report that it doesn't actually know the mode.) --Andy