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 A09B7C4332F for ; Mon, 6 Nov 2023 10:24:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C2308D0013; Mon, 6 Nov 2023 05:24:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 373308D0002; Mon, 6 Nov 2023 05:24:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EC778D0013; Mon, 6 Nov 2023 05:24:26 -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 045D48D0002 for ; Mon, 6 Nov 2023 05:24:26 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B653EB52E4 for ; Mon, 6 Nov 2023 10:24:25 +0000 (UTC) X-FDA: 81427144890.23.03630C5 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf22.hostedemail.com (Postfix) with ESMTP id C7350C0012 for ; Mon, 6 Nov 2023 10:24:23 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=bLyrDDex; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699266263; 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=Jx7pzo9zslWgjVRljunAjs24sdVG2mkanbp0iYdFwaI=; b=k83i+siDsvhGQnqyO13DA+GIDKYfNwf2XCZAEEDvBsrCVJY7Nbskd/EUE9QHsWCePgychC tEn2JG9yTVre91ORJ/lPMfk75gv66asxdEovATHsMnwyRHpLAM8+qxCeEthDj+9q5cY7JY PKInMC9oN6dBLY7Q8R4GsVJNI9cArBc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=bLyrDDex; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of tabba@google.com designates 209.85.219.53 as permitted sender) smtp.mailfrom=tabba@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699266263; a=rsa-sha256; cv=none; b=K5L8N8RjUFyGPkRQVCjYfUQaKgDCttFztWNkr7eQj5aHD69+IftArHzUwN4SPC2jrvkCia LeSf0ydTBMS8/gbNs4Xvd5sAKEeMupNPJ727wp1QGHOTlsnHVWYs7jTcaltuB1NjcBx3TE uSbUPdDQMJbFAi04ysv7+fEG9s/BGPs= Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-66d093265dfso26744246d6.3 for ; Mon, 06 Nov 2023 02:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699266263; x=1699871063; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Jx7pzo9zslWgjVRljunAjs24sdVG2mkanbp0iYdFwaI=; b=bLyrDDex+/G8h/hjpq4MJib3AHWRNfIzBZtxbI1bGrnrgUOcgIEryfH11AMVe6jeLp Klporo5arRTdo9M0tTyvyzSjTqrgrMuWVueXKi+T26R3ZrrlmDqX+l084/7XAbs7DtbD 7SCW7KodYASekswIixTMjr4DMhtaNjdb3u2Z/5lqycGI5WsMjxWzaQzc/FY9v4h/QbN4 rm92D/9RXfrcgK0Im/+upUeplZeav7/KYGiQjeWEvU+Zv/YTpBfPmFc/C8BLzYUwZcwv q3RF1cyIEoKo54zfKPdNNXzBwd4BVQG9DngXvnteBp44L09efwf59WCvD+buBVoBYGCI d7Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699266263; x=1699871063; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Jx7pzo9zslWgjVRljunAjs24sdVG2mkanbp0iYdFwaI=; b=hPgo8tWU5lfFfLLLtkQmPaOE1Cybq62rF/vHBtNsFJNmAOW9XvcIoYaoJIKuCuwV/m wfQgdZR3WTUu0ylSaXD6Wprr95ePn+IWI7IsbW8vYcG/X48TxsfW5Cfu7fWQcniGpanx 0YlK5U8eek+DteUZ8Q7ywuseqFIhCeAj4oCnJXmXhZ/SJ1e+QYlTchJ0K8wNk1TGU9NS h1u7/bMSv77G0gf84W1bU6Bo9r+f1+g2uhNO7+6oTsr7h/PDzntnxSlA+5MrlAV0BWHw l5NG3wTWbuUDsG4hJBkck2ButiQ2Ky0S3ooH8mJSOQv8ehX1/HHnEdTXLMTxFr33bmZs V+yA== X-Gm-Message-State: AOJu0Yw5tjPMkU2XGTkAPFm+cn7Ju1d9LoWKHTql1jZUiM2lPw9w5ZMj TxCxyOxsGVo3J0WoSP93yQmgxUQr04l8HhMtiBWs8Q== X-Google-Smtp-Source: AGHT+IGxqUy2TkFSF/6DzAsvotrbwxLeZiINpO4wtvkCRKfv4JWO0abdv88fQIT6HNBLh2pi2NT5y8KzEPnGx9OmZnQ= X-Received: by 2002:ad4:5aa3:0:b0:66d:bc21:814c with SMTP id u3-20020ad45aa3000000b0066dbc21814cmr37429526qvg.65.1699266262770; Mon, 06 Nov 2023 02:24:22 -0800 (PST) MIME-Version: 1.0 References: <20231105163040.14904-1-pbonzini@redhat.com> <20231105163040.14904-10-pbonzini@redhat.com> In-Reply-To: <20231105163040.14904-10-pbonzini@redhat.com> From: Fuad Tabba Date: Mon, 6 Nov 2023 10:23:46 +0000 Message-ID: Subject: Re: [PATCH 09/34] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace To: Paolo Bonzini Cc: Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Sean Christopherson , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , 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 , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A. Shutemov" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C7350C0012 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: de9gdqwg355ahtq46um5ct5hab6iq4ht X-HE-Tag: 1699266263-767698 X-HE-Meta: U2FsdGVkX1+GVTNyos9xo2rvQJNwh7je6k5qxo9Tx9W+rRnqvztwCBnyxO0bAzsrwsUZJcQqVgojAgqxsYRXD/W4IhIwSo1G5jQRLkg/oyrv4usL9YVrhRpEbWqCCJYkieJWaUXIOoTBi3sVLAdn127vwSgwPPdQiCsAuF5y5rgvQ49wESTvHIHjN9+jwD5hJFfX1p6XBrfyMFmuvHpKS5EMCb49u+Gqx3ODDqrV32IYXdx1ievP1sM0bR4kn13Owusn6nRpivAPWEuZoY/068alL1Gf1bQfV3V+PzmtXeyDYUUwo47t/Y4cM7xaCGGOJh/Wy0cor2T3L95aE8Az4ISqb5ZnmsgskIrsTkurCsaB67O0CHNS7yblUjoJqDM7JriwjxuriLZ3V3u+G+UWJw7eM7yzY1aaJ3W7WVOVaMSOcA51dH5OlyggivUUxhvv5h3srQ2oVteQh1APysvpYcay7bMevHgcBgf2LsIn9WRLBUS2Cqv0NrAmVC7OOeHhM4wcfozpnmv4qSoh0XefkWARiFUH4Y0Q8EnVmsok6q7jo2XpeSrSSEYgi5FI2s91xjPC/dwi4cEm0F35Wl7DFJDsOPMLDqCmSgw47I//cIgimiT0welZfpqO1bgZzFqJlJVdw2yvQKH5dzd1XTnqeFI1U1z9Px7V9EMO+mG68+CI5KyDJtQGkuUOmKLxp2tlUsUFRzJiQeOpYUo/VW0grnfAeO2EqxrzIZ8YNdmdff9KXogFjBuI2nrRnX+Cru9Jv0WgQy/UBm9yVojcmTA2SDFj/+DkTGECs/IvXNV8+uX0E66L5TkuC3868YzZOPD8RL0rV6hr3ZwDysVz2GdfY9b6uMzFFGAjGGTXCfdqTRVrw4Ms4wf9mwku2XjkAClPb+/pPjM/xCHsAOtmpHqU/eecX+mUQx3F4fnI0BOI/K8K/qDHVaxIjItaAtMlwQnvckWH3ML2GGdD3bCIsx0 Y5B8om6j bU4p8c8O8N5OAv/c1UX+VfbpJ4A8J9qGbZ51gGJsxe9E1tZASJJtvDheMFPxgf5uAy5+OXxyV6RaxI51G9PyPKXct6B+VPrjEoDa2maEp4CnlijBBEdgEcyuL7FojbVozij4PipKtzDmLlPcYWztpuHfn7kYAo2JP3p3WhspV2vYmpPd2KfVC5NIXGK/CPMjf6XjWJW9feR6sJMm6taSqyI43rCOLQ3BilacFJ5Y0Rbkl53TNVSgfyCcGLyUwsI8s06czIUYGB50XlEKN60HZ8JEgga+5jJlf9LtEWUi7gw80uDCo4SkTWsb/c1LCogvJGNiB/FgdvBn6lK2cIH3OQtY49UQeHCZc1RgmADeoue1GEriqQKodyxCzIT4AErBDvodmDVrkdaVHdqn4S/JUsdafZ3uIqJYHk/UXNnpF7sNgDobS+IYPCMlpDj9pm9LNUsFfQ/vvYDZldXL9IX7l64Lb0ZVsy00lJTVcEYEB/+NXkAhph3VrH7J75w== 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 Sun, Nov 5, 2023 at 4:32=E2=80=AFPM Paolo Bonzini = 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 =3D=3D 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, likel= y > 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@googl= e.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 > Message-Id: <20231027182217.3615211-10-seanjc@google.com> > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Fuad Tabba Tested-by: Fuad Tabba Cheers, /fuad > 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 bdea1423c5f8..481fb0e2ce90 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6846,6 +6846,26 @@ array field represents return values. The userspac= e 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_fault; > + > +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 tha= t 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 */ > @@ -7880,6 +7900,27 @@ This capability is aimed to mitigate the threat th= at 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 v= irtual > +address. > + > +The information in kvm_run.memory_fault is valid if and only if KVM_RUN = returns > +an error with errno=3DEFAULT or errno=3DEHWPOISON *and* kvm_run.exit_rea= son 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. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 7b389f27dffc..8f9d8939b63b 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4625,6 +4625,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, l= ong 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 =3D 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 =3D KVM_EXIT_MEMORY_FAULT; > + vcpu->run->memory_fault.gpa =3D gpa; > + vcpu->run->memory_fault.size =3D size; > + > + /* Flags are not (yet) defined or communicated to userspace. */ > + vcpu->run->memory_fault.flags =3D 0; > +} > + > #endif > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 308cc70bd6ab..59010a685007 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -275,6 +275,7 @@ struct kvm_xen_exit { > #define KVM_EXIT_RISCV_CSR 36 > #define KVM_EXIT_NOTIFY 37 > #define KVM_EXIT_LOONGARCH_IOCSR 38 > +#define KVM_EXIT_MEMORY_FAULT 39 > > /* For KVM_EXIT_INTERNAL_ERROR */ > /* Emulate instruction failed. */ > @@ -528,6 +529,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]; > }; > @@ -1212,6 +1219,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229 > #define KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES 230 > #define KVM_CAP_USER_MEMORY2 231 > +#define KVM_CAP_MEMORY_FAULT_INFO 232 > > #ifdef KVM_CAP_IRQ_ROUTING > > -- > 2.39.1 > >