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 AFA49C4332F for ; Mon, 30 Oct 2023 17:22:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A5666B025C; Mon, 30 Oct 2023 13:22:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 353716B025E; Mon, 30 Oct 2023 13:22:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F4CC6B025F; Mon, 30 Oct 2023 13:22:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0E6146B025C for ; Mon, 30 Oct 2023 13:22:47 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CF95B1CB61A for ; Mon, 30 Oct 2023 17:22:46 +0000 (UTC) X-FDA: 81402797532.27.943E124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 8A25B1A001A for ; Mon, 30 Oct 2023 17:22:44 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="LGL6/Q9+"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698686564; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6ITwAt3fuOh2cDBi6BB8DUSA16OthbZCN3xR2w5GAmk=; b=aTZutFMZ5IeOpb4O5SuCJfN/cLsg1EojmbXE955PsoUinErQBdlLsSd0Bs1bmcrZ3ptJP6 OwTjaYJb4UFnqyRm05Hj37vy/lJ6vJysMGOBUWBzo4DKupvbWW3uiOxtNtkwgBUWy8Abnr ZbtRzYp5gnANNZejn4Y+ngnJ4kg81KU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="LGL6/Q9+"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of pbonzini@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pbonzini@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698686564; a=rsa-sha256; cv=none; b=4FjQbSLFtREIfvb3nRrrkAimKzgEX7L1KC7gWL9sxHDSHXiaSjWYxx3avG7RbaaROMUK6C i4+VayeMkVw7993U7v8QL3PGF58wKI94VFHz1pZ3FNxnIP+xThQtkZ7N/wJItxJC21RorH JcZgGRAR9mUatUSpY2SXXAuRcy+SP1Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698686563; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=6ITwAt3fuOh2cDBi6BB8DUSA16OthbZCN3xR2w5GAmk=; b=LGL6/Q9+5G1TPgP4FhwiGehBnWWSbBpHlLZGxdtM+rYbJZnlGhzoYcCpf2bInO0462ZdSv C4mmjhOcJj6x798VS6r6axkiTHpYdC9/f0g+HKGXyPpwNzJkP9iYtOYPJWornAIzxPBoCk wcToFZ1UGI/6RRAhidSDs9j7wsTPe+c= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-562-PbEaRYUKM321mJ9ZVLXoEw-1; Mon, 30 Oct 2023 13:22:40 -0400 X-MC-Unique: PbEaRYUKM321mJ9ZVLXoEw-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-40855a91314so31963475e9.1 for ; Mon, 30 Oct 2023 10:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698686555; x=1699291355; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6ITwAt3fuOh2cDBi6BB8DUSA16OthbZCN3xR2w5GAmk=; b=MI652QlLzscMF/ni6gXuOJii4dYgJswxdHXGxzDEPpp4NrEJm2T/6SrGP/xInm3s7v ARxhh5ci3uuydLzQ85pswlvAP6/ETtU/brFNV0h1QiPGaBXDcVVWR54bKztmjkD4BKOa nH/9OZVR8eMY34qg0cW33aCvNoEmX9nC0pjd7/MuA9t5ubUNXhcRdkoEDUY3lyScdVxW B91g2QE3M3KepiQcpExtFENe1JSu5MopBaLB23WB2OyyDdWJnlxShkOr8HywEZn0g88E G6hUcQUdBU/0BdSHb8CYwA7dw/FYSI+CRCShJZ6UYK8IeZgTGVWyoC5dm/SDZxnEm9mx ECBQ== X-Gm-Message-State: AOJu0Yynqfh6L7sYC0vS6sQgqU66KqwILrJsYPB4pj37OZV42ttp34Hl iwyE4dpJ6zGyaUZhdSTZC0/3G/dthUR5WUOHyrwj93YkduwzS+CjARL3hIniRhsGUR7kCuLaTqR +hNpY0QunTls= X-Received: by 2002:a05:600c:45cd:b0:407:4701:f9e with SMTP id s13-20020a05600c45cd00b0040747010f9emr296191wmo.17.1698686555024; Mon, 30 Oct 2023 10:22:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEsBlg/6wPDQVRi/nfUx2iIcHKNVjd7bvALhjURWCUu+koDyl9/DjnrY9Jn65zYlgTA6JZouA== X-Received: by 2002:a05:600c:45cd:b0:407:4701:f9e with SMTP id s13-20020a05600c45cd00b0040747010f9emr296155wmo.17.1698686554568; Mon, 30 Oct 2023 10:22:34 -0700 (PDT) Received: from [192.168.1.174] ([151.81.68.207]) by smtp.googlemail.com with ESMTPSA id c5-20020a05600c0a4500b004094d4292aesm430163wmq.18.2023.10.30.10.22.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Oct 2023 10:22:33 -0700 (PDT) Message-ID: <904fd341-7bfd-4b63-a2ed-16c9249e698e@redhat.com> Date: Mon, 30 Oct 2023 18:22:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace To: Sean Christopherson , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8?= =?UTF-8?Q?n?= , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> From: Paolo Bonzini Autocrypt: addr=pbonzini@redhat.com; keydata= xsEhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAc0j UGFvbG8gQm9uemluaSA8cGJvbnppbmlAcmVkaGF0LmNvbT7CwU0EEwECACMFAlRCcBICGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRB+FRAMzTZpsbceDp9IIN6BIA0Ol7MoB15E 11kRz/ewzryFY54tQlMnd4xxfH8MTQ/mm9I482YoSwPMdcWFAKnUX6Yo30tbLiNB8hzaHeRj jx12K+ptqYbg+cevgOtbLAlL9kNgLLcsGqC2829jBCUTVeMSZDrzS97ole/YEez2qFpPnTV0 VrRWClWVfYh+JfzpXmgyhbkuwUxNFk421s4Ajp3d8nPPFUGgBG5HOxzkAm7xb1cjAuJ+oi/K CHfkuN+fLZl/u3E/fw7vvOESApLU5o0icVXeakfSz0LsygEnekDbxPnE5af/9FEkXJD5EoYG SEahaEtgNrR4qsyxyAGYgZlS70vkSSYJ+iT2rrwEiDlo31MzRo6Ba2FfHBSJ7lcYdPT7bbk9 AO3hlNMhNdUhoQv7M5HsnqZ6unvSHOKmReNaS9egAGdRN0/GPDWr9wroyJ65ZNQsHl9nXBqE AukZNr5oJO5vxrYiAuuTSd6UI/xFkjtkzltG3mw5ao2bBpk/V/YuePrJsnPFHG7NhizrxttB nTuOSCMo45pfHQ+XYd5K1+Cv/NzZFNWscm5htJ0HznY+oOsZvHTyGz3v91pn51dkRYN0otqr bQ4tlFFuVjArBZcapSIe6NV8C4cEiSTOwE0EVEJx7gEIAMeHcVzuv2bp9HlWDp6+RkZe+vtl KwAHplb/WH59j2wyG8V6i33+6MlSSJMOFnYUCCL77bucx9uImI5nX24PIlqT+zasVEEVGSRF m8dgkcJDB7Tps0IkNrUi4yof3B3shR+vMY3i3Ip0e41zKx0CvlAhMOo6otaHmcxr35sWq1Jk tLkbn3wG+fPQCVudJJECvVQ//UAthSSEklA50QtD2sBkmQ14ZryEyTHQ+E42K3j2IUmOLriF dNr9NvE1QGmGyIcbw2NIVEBOK/GWxkS5+dmxM2iD4Jdaf2nSn3jlHjEXoPwpMs0KZsgdU0pP JQzMUMwmB1wM8JxovFlPYrhNT9MAEQEAAcLBMwQYAQIACQUCVEJx7gIbDAAKCRB+FRAMzTZp sadRDqCctLmYICZu4GSnie4lKXl+HqlLanpVMOoFNnWs9oRP47MbE2wv8OaYh5pNR9VVgyhD OG0AU7oidG36OeUlrFDTfnPYYSF/mPCxHttosyt8O5kabxnIPv2URuAxDByz+iVbL+RjKaGM GDph56ZTswlx75nZVtIukqzLAQ5fa8OALSGum0cFi4ptZUOhDNz1onz61klD6z3MODi0sBZN Aj6guB2L/+2ZwElZEeRBERRd/uommlYuToAXfNRdUwrwl9gRMiA0WSyTb190zneRRDfpSK5d usXnM/O+kr3Dm+Ui+UioPf6wgbn3T0o6I5BhVhs4h4hWmIW7iNhPjX1iybXfmb1gAFfjtHfL xRUr64svXpyfJMScIQtBAm0ihWPltXkyITA92ngCmPdHa6M1hMh4RDX+Jf1fiWubzp1voAg0 JBrdmNZSQDz0iKmSrx8xkoXYfA3bgtFN8WJH2xgFL28XnqY4M6dLhJwV3z08tPSRqYFm4NMP dRsn0/7oymhneL8RthIvjDDQ5ktUjMe8LtHr70OZE/TT88qvEdhiIVUogHdo4qBrk41+gGQh b906Dudw5YhTJFU3nC6bbF2nrLlB4C/XSiH76ZvqzV0Z/cAMBo5NF/w= In-Reply-To: <20231027182217.3615211-10-seanjc@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8A25B1A001A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mtjkmmpbdzpgdczukrbzqn41ji1hzht5 X-HE-Tag: 1698686564-521607 X-HE-Meta: U2FsdGVkX19I2GFt+XFuUwUAgSxnmuUFzZ4MAEqlZ3bmN/Ie88jhWbYt7ay9OQRShuCPJDhmG5VDiU5LGmGOJZhJ7gnlq2mN41fynFWM4fdOKkAk3W44LEDlmFNJFsvmM6aQJY9ISa768kFXNrToSwmzVuhy+371jdBroax/fmO+/gj63g41MAhxhBeWh1NuS0dmudwPoIzTlyBBZJmrZeHM1LozZYDrFuMGRTPcsecClD560ji2Y+fmo5dE9WVdgtiu95VFFW3+8dcyW2vlVtd6QPsaGahG6PmfI8wark6GLk5frHvJ/f3umpprCLf7urjKhZAVOZTnC5v8/vRdbrIclRbgCp/HtXJgrkjecTR9tezFZlfN3PnIUOt11wqQNv2ScOq2+kI9EKkRauy5+qbYzrnPi9kO1sOQRAHfbP0FpaW6dDZ5uhQJAIrPCmkxi4T8Bh0SJ87GDh2kjDNBKEPKh9oZum6ke07pWkA8Fyq0rKnv2TvdlF9J/BbUvtpCV+732S1EtbLoXYva42Hzj8EyMIio+sSbn9BmpzK4OZ5IIIh3QhbFwsgNyTY6FMin3fpzWwLCJuG7SWjqmR1twTDY2gaiMP2vxgbysT6IYMM5MSWj3um7mqxFKKTxQayeIfkrea3Jsd87ogUESDQ8dAPz47+O9KZF0/I+TH05WlT1APHbIFRlgYku4kAvAiKqQDeh+hwkSpctjfdHiN0tra0vL5SgFqJD2+miz+0igVHlv7WwxMN77cGg98SqssUgU4SoNEYwwybvzVYl5w2SazuD78el26GBzPbQnCOq/209h9Nga309n0sUQC6NHeca/pFfyzV0FCSDI7KpM1z3lPAJ8/kVgJQnTwtxoZ7n5AsrmxkbKDzG+wxrjO45CkYzLuooXFBKbd8Zzx/QzKvNE6BbykShwlP2ssDPBapQLYeD1I03PSgpyTe5wF2j8XD8BsfRNl4Qr5DyQ33LJEv hi4C3JDo e/H6+9wgwgj+NL0yNO06LmpMPqSJm0sIIEYjOFgXeMNws+lkxWURrTHHpwoeM6zYa6jE7LCaaG1RjsAuN0vSN3nhzGtY+fvFZ/qAxZVYJlKxFAKHkupFODlN2oHspZ/EW5mdV72acYOQcjPI0Bj2c7kHCB53jE1sVID/8nNIyFopuG2fQpLD9BWu8C43pS3pHkk8nMi1J4DDT7VmMhSoRitAfxbomk/a6aQZLhNkQXEl+qrfITKWlyTtXDuTnBIs6Lu1UYgO8vmZSQVmp/J3w95D6yK+WI3PMnaIvB5lrFAKnte+1l3Aw6PVYozxTZ3uuv8zvro9LVL/g9y/XffGczbxSgGW4CghOWdAgbeX/k2toLWhb9FZdoU7IlCLaFL6gib4+mb7mgGDeX5XtckujeUS/vATnN6pFH0qItDs5nGui+qWvESIua7y0Y3RDO+4LZXtRirQ20KKlpIgU7Y/rxLek1JxonjCCtso8I/najd6h7ux/OMgEWRpaBCnICG7MNpt+aIBpmb4UX4hUT6MeE+oBiP0FDWxbN1d9tGgGUQJRnPpKLFhk6Hrm/6UbR9k2SDUDBvUpK15ts0beoO/DeYtlG/kjJ1L9OPdZCNRc7f9eL76DIwC0UOGNyxYVnXw4S4Jjm8FktEoQt6+h7ZwqZbYTJEOz6v+GPQIUKMGLHYTvtYw= 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: List-Subscribe: List-Unsubscribe: On 10/27/23 20:21, Sean Christopherson wrote: > From: Chao Peng > > Add a new KVM exit type to allow userspace to handle memory faults that > KVM cannot resolve, but that userspace *may* be able to handle (without > terminating the guest). > > KVM will initially use KVM_EXIT_MEMORY_FAULT to report implicit > conversions between private and shared memory. With guest private memory, > there will be two kind of memory conversions: > > - explicit conversion: happens when the guest explicitly calls into KVM > to map a range (as private or shared) > > - implicit conversion: happens when the guest attempts to access a gfn > that is configured in the "wrong" state (private vs. shared) > > On x86 (first architecture to support guest private memory), explicit > conversions will be reported via KVM_EXIT_HYPERCALL+KVM_HC_MAP_GPA_RANGE, > but reporting KVM_EXIT_HYPERCALL for implicit conversions is undesriable > as there is (obviously) no hypercall, and there is no guarantee that the > guest actually intends to convert between private and shared, i.e. what > KVM thinks is an implicit conversion "request" could actually be the > result of a guest code bug. > > KVM_EXIT_MEMORY_FAULT will be used to report memory faults that appear to > be implicit conversions. > > Note! To allow for future possibilities where KVM reports > KVM_EXIT_MEMORY_FAULT and fills run->memory_fault on _any_ unresolved > fault, KVM returns "-EFAULT" (-1 with errno == EFAULT from userspace's > perspective), not '0'! Due to historical baggage within KVM, exiting to > userspace with '0' from deep callstacks, e.g. in emulation paths, is > infeasible as doing so would require a near-complete overhaul of KVM, > whereas KVM already propagates -errno return codes to userspace even when > the -errno originated in a low level helper. > > Report the gpa+size instead of a single gfn even though the initial usage > is expected to always report single pages. It's entirely possible, likely > even, that KVM will someday support sub-page granularity faults, e.g. > Intel's sub-page protection feature allows for additional protections at > 128-byte granularity. > > Link: https://lore.kernel.org/all/20230908222905.1321305-5-amoorthy@google.com > Link: https://lore.kernel.org/all/ZQ3AmLO2SYv3DszH@google.com > Cc: Anish Moorthy > Cc: David Matlack > Suggested-by: Sean Christopherson > Co-developed-by: Yu Zhang > Signed-off-by: Yu Zhang > Signed-off-by: Chao Peng > Co-developed-by: Sean Christopherson > Signed-off-by: Sean Christopherson Reviewed-by: Paolo Bonzini > --- > Documentation/virt/kvm/api.rst | 41 ++++++++++++++++++++++++++++++++++ > arch/x86/kvm/x86.c | 1 + > include/linux/kvm_host.h | 11 +++++++++ > include/uapi/linux/kvm.h | 8 +++++++ > 4 files changed, 61 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index ace984acc125..860216536810 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6723,6 +6723,26 @@ 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 { > + __u64 flags; > + __u64 gpa; > + __u64 size; > + } memory; > + > +KVM_EXIT_MEMORY_FAULT indicates the vCPU has encountered a memory fault that > +could not be resolved by KVM. The 'gpa' and 'size' (in bytes) describe the > +guest physical address range [gpa, gpa + size) of the fault. The 'flags' field > +describes properties of the faulting access that are likely pertinent. > +Currently, no flags are defined. > + > +Note! KVM_EXIT_MEMORY_FAULT is unique among all KVM exit reasons in that it > +accompanies a return code of '-1', not '0'! errno will always be set to EFAULT > +or EHWPOISON when KVM exits with KVM_EXIT_MEMORY_FAULT, userspace should assume > +kvm_run.exit_reason is stale/undefined for all other error numbers. > + > :: > > /* KVM_EXIT_NOTIFY */ > @@ -7757,6 +7777,27 @@ This capability is aimed to mitigate the threat that malicious VMs can > cause CPU stuck (due to event windows don't open up) and make the CPU > unavailable to host or other VMs. > > +7.34 KVM_CAP_MEMORY_FAULT_INFO > +------------------------------ > + > +:Architectures: x86 > +:Returns: Informational only, -EINVAL on direct KVM_ENABLE_CAP. > + > +The presence of this capability indicates that KVM_RUN will fill > +kvm_run.memory_fault if KVM cannot resolve a guest page fault VM-Exit, e.g. if > +there is a valid memslot but no backing VMA for the corresponding host virtual > +address. > + > +The information in kvm_run.memory_fault is valid if and only if KVM_RUN returns > +an error with errno=EFAULT or errno=EHWPOISON *and* kvm_run.exit_reason is set > +to KVM_EXIT_MEMORY_FAULT. > + > +Note: Userspaces which attempt to resolve memory faults so that they can retry > +KVM_RUN are encouraged to guard against repeatedly receiving the same > +error/annotated fault. > + > +See KVM_EXIT_MEMORY_FAULT for more information. > + > 8. Other capabilities. > ====================== > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 6409914428ca..ee3cd8c3c0ef 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4518,6 +4518,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ENABLE_CAP: > case KVM_CAP_VM_DISABLE_NX_HUGE_PAGES: > case KVM_CAP_IRQFD_RESAMPLE: > + case KVM_CAP_MEMORY_FAULT_INFO: > r = 1; > break; > case KVM_CAP_EXIT_HYPERCALL: > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 4e741ff27af3..96aa930536b1 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -2327,4 +2327,15 @@ static inline void kvm_account_pgtable_pages(void *virt, int nr) > /* Max number of entries allowed for each kvm dirty ring */ > #define KVM_DIRTY_RING_MAX_ENTRIES 65536 > > +static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu, > + gpa_t gpa, gpa_t size) > +{ > + vcpu->run->exit_reason = KVM_EXIT_MEMORY_FAULT; > + vcpu->run->memory_fault.gpa = gpa; > + vcpu->run->memory_fault.size = size; > + > + /* Flags are not (yet) defined or communicated to userspace. */ > + vcpu->run->memory_fault.flags = 0; > +} > + > #endif > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index bd1abe067f28..7ae9987b48dd 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -274,6 +274,7 @@ struct kvm_xen_exit { > #define KVM_EXIT_RISCV_SBI 35 > #define KVM_EXIT_RISCV_CSR 36 > #define KVM_EXIT_NOTIFY 37 > +#define KVM_EXIT_MEMORY_FAULT 38 > > /* For KVM_EXIT_INTERNAL_ERROR */ > /* Emulate instruction failed. */ > @@ -520,6 +521,12 @@ struct kvm_run { > #define KVM_NOTIFY_CONTEXT_INVALID (1 << 0) > __u32 flags; > } notify; > + /* KVM_EXIT_MEMORY_FAULT */ > + struct { > + __u64 flags; > + __u64 gpa; > + __u64 size; > + } memory_fault; > /* Fix the size of the union. */ > char padding[256]; > }; > @@ -1203,6 +1210,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228 > #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229 > #define KVM_CAP_USER_MEMORY2 230 > +#define KVM_CAP_MEMORY_FAULT_INFO 231 > > #ifdef KVM_CAP_IRQ_ROUTING >