From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Wed, 1 Nov 2023 10:36:48 -0700 Subject: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace In-Reply-To: <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Nov 01, 2023, Kai Huang wrote: > > > +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. > > IIUC returning -EFAULT or whatever -errno is sort of KVM internal > implementation. The errno that is returned to userspace is ABI. In KVM, it's a _very_ poorly defined ABI for the vast majority of ioctls(), but it's still technically ABI. KVM gets away with being cavalier with errno because the vast majority of errors are considered fatal by userespace, i.e. in most cases, userspace simply doesn't care about the exact errno. A good example is KVM_RUN with -EINTR; if KVM were to return something other than -EINTR on a pending signal or vcpu->run->immediate_exit, userspace would fall over. > Is it better to relax the validity of kvm_run.memory_fault when > KVM_RUN returns any -errno? Not unless there's a need to do so, and if there is then we can update the documentation accordingly. If KVM's ABI is that kvm_run.memory_fault is valid for any errno, then KVM would need to purge kvm_run.exit_reason super early in KVM_RUN, e.g. to prevent an -EINTR return due to immediate_exit from being misinterpreted as KVM_EXIT_MEMORY_FAULT. And purging exit_reason super early is subtly tricky because KVM's (again, poorly documented) ABI is that *some* exit reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a pending signal). https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf at google.com > [...] > > > > --- 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; > > +} > > + > > KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to > ? I'd prefer to keep it in generic code, as it's highly likely to end up there sooner than later. There's a known use case for ARM (exit to userspace on missing userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API. [*] https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy at google.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF9E4D26B for ; Wed, 1 Nov 2023 17:36:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="uqnmvVBP" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-da0c7d27fb0so6524151276.1 for ; Wed, 01 Nov 2023 10:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698860209; x=1699465009; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=uqnmvVBPSYUgr/3uZVysNVOyN3Ppj4OSpb2ICWYS5S6AujI/kDJdZ3iGN/iphB1WnX sXX+0j1p2ZvXSwAuZcY+asbc3viMBTZMdFCL2kO3IciAwqYb+XYR5t66ZZ/veWWGWN9H pWluSj2PdptRq7sWzXV5kFIw9duEbe1vMVdURLwt5m3BMmMFpYSHV56ei9EBKAr1a9UB MDF3L5a6a+uaubs6YLFc30UObQ9X6MFFd5ANIvhzC7X+622umhaxEskXxAv1ma79qIh6 pETcxo+EUbmBRkYbxEY5F+UJXbXLcBcBMCP3kg/p59zDppljbFcpZPmaaXF9RMAa+Cdr Vgzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698860209; x=1699465009; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=Cy6re+WTwFni7AHrakapnbwzJvkwQBNWu8RMplKY7QhLt1iv2kpMkoAhMNsPYJ5vz0 u0WJ1uHAxvO18m6dkpJkwGWuwQC8KnEYn6SZtWB3Oa4CBGQySc2OYwD+G1RaKqbZnxZN mO6/H9yQZZEbcMMQrWAy18CBkSVrk6ph6MHAq2vGE7/fUi8GmswUdiXLNDtEDSr6/TXk hTIHjdsknL6kThmSvvQMdB7gl56uC2EC6XWCm4cW1NMSXUxaeWj+zb6YcOPD1VGN8oqx yJNOysVj8o9L6LTth1wNn7PTy+28d6cx9uSXI47LcB5aZpE/3H2gUcvxuWZmWicpxUHI 6kgA== X-Gm-Message-State: AOJu0Yzcigz2t5WkWdwfROQvRhLh5AOW+XfJ2chjYb81WkOtvGUd9swu i32cGq25rcynlp2V6uqaOfJerISyTq0= X-Google-Smtp-Source: AGHT+IG/a6Sj0mASs5/8PEJQnR69sSphX+9SHKWYEjRPOLGEF4l6c52AgzjYtmdhHr7JL68mzkGP7JI8NEg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:168c:b0:da0:3e46:8ba5 with SMTP id bx12-20020a056902168c00b00da03e468ba5mr304342ybb.8.1698860209654; Wed, 01 Nov 2023 10:36:49 -0700 (PDT) Date: Wed, 1 Nov 2023 10:36:48 -0700 In-Reply-To: <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Message-ID: Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Kai Huang Cc: "viro@zeniv.linux.org.uk" , "aou@eecs.berkeley.edu" , "brauner@kernel.org" , "oliver.upton@linux.dev" , "chenhuacai@kernel.org" , "paul.walmsley@sifive.com" , "palmer@dabbelt.com" , "maz@kernel.org" , "pbonzini@redhat.com" , "mpe@ellerman.id.au" , "willy@infradead.org" , "anup@brainfault.org" , "akpm@linux-foundation.org" , Xiaoyao Li , "kvm-riscv@lists.infradead.org" , "mic@digikod.net" , "liam.merwick@oracle.com" , "kvm@vger.kernel.org" , Isaku Yamahata , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "tabba@google.com" , "amoorthy@google.com" , "linuxppc-dev@lists.ozlabs.org" , "michael.roth@amd.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "chao.p.peng@linux.intel.com" , "linux-mips@vger.kernel.org" , Vishal Annapurve , "vbabka@suse.cz" , "mail@maciej.szmigiero.name" , "yu.c.zhang@linux.intel.com" , "qperret@google.com" , "dmatlack@google.com" , Yilun Xu , "isaku.yamahata@gmail.com" , "ackerleytng@google.com" , "jarkko@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Wei W Wang Content-Type: text/plain; charset="us-ascii" On Wed, Nov 01, 2023, Kai Huang wrote: > > > +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. > > IIUC returning -EFAULT or whatever -errno is sort of KVM internal > implementation. The errno that is returned to userspace is ABI. In KVM, it's a _very_ poorly defined ABI for the vast majority of ioctls(), but it's still technically ABI. KVM gets away with being cavalier with errno because the vast majority of errors are considered fatal by userespace, i.e. in most cases, userspace simply doesn't care about the exact errno. A good example is KVM_RUN with -EINTR; if KVM were to return something other than -EINTR on a pending signal or vcpu->run->immediate_exit, userspace would fall over. > Is it better to relax the validity of kvm_run.memory_fault when > KVM_RUN returns any -errno? Not unless there's a need to do so, and if there is then we can update the documentation accordingly. If KVM's ABI is that kvm_run.memory_fault is valid for any errno, then KVM would need to purge kvm_run.exit_reason super early in KVM_RUN, e.g. to prevent an -EINTR return due to immediate_exit from being misinterpreted as KVM_EXIT_MEMORY_FAULT. And purging exit_reason super early is subtly tricky because KVM's (again, poorly documented) ABI is that *some* exit reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a pending signal). https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > [...] > > > > --- 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; > > +} > > + > > KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to > ? I'd prefer to keep it in generic code, as it's highly likely to end up there sooner than later. There's a known use case for ARM (exit to userspace on missing userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API. [*] https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy@google.com 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8BB66C4332F for ; Wed, 1 Nov 2023 17:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=PtdKZ+sDKkt7ieC/RVOKSUs68T8wYfZO4L17JEc86Us=; b=YsHeiECyArNTtHwuAfvL6vpGnV Frns2qjfUU2jaU97D0RPMIZraNsKIN9eYncmEa2pdYhJ2ORoRkVYVbSmjzlTO8vLM/B1hS8k3jd85 5dhD/iP0dPQUEJh/JXYagrZaAbm7Mu3JHV5AYecyp+9V/jhxxHzGoyj7t2Q9Kn0hxWUGUm09BO8tP 3HLtfztOEy0igwJ4s0oXvsa5dSfcE9nCf577VNWu/t5m+Qf1AsQTDpI3sa0kusBsbfHhRFnsERFoX k+QPXK3pic1wG1++eSsHm8vxPMEvxvDcjWjpnSUtivrunEO0nGOPSo994SAOdUhksWb6hYIHsE5Lo kwa2nCRA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qyF9D-007t3e-1Z; Wed, 01 Nov 2023 17:36:55 +0000 Received: from mail-yb1-xb4a.google.com ([2607:f8b0:4864:20::b4a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qyF9B-007t2m-08 for linux-riscv@lists.infradead.org; Wed, 01 Nov 2023 17:36:54 +0000 Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-da03390793fso7108560276.3 for ; Wed, 01 Nov 2023 10:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698860209; x=1699465009; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=fsWpC2RbvONMs14YuuPPJ87cpSMciGnAp3NRcfWv9OyXeXZNvgSWupK0xUpWdyxBGo N36noxpgT0QR315yX3qcrTr/jpAvzd38Y4hKG1B7cXvQwPNpDcjZsnMdLTM7Yk2mPRK1 JK6ldkc2i95VZ1lvxkzRwxnwkdZ+7zQrfhbe3+gc5qJw0u3TDX7WZD34Da1xbDDlergl Or/4zGeuB3YBczWd975+NLs/f0dZGC0E2dDkBrvM4MoGUGas+B9oJZlhILEjU98M+Beo 7Q0dglUyPstrdb6sMJ2wL+BAtbbcbVX/TTN/kXgZ/881m4bNSO4snBvlaj8QSzEUD+Ep 3nLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698860209; x=1699465009; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=MWxA88vfIrX8Kb9af1xHGSJGxR31xDB1AVcUMYKTZ2ZJ7uowHML5JyJL8ul+3/g9Ub iUvR2nbD6NcAnB3xtsLzMiJVmA+zIzeyFUaAKugR3BpqUhcR+UplDM9WBg2QPMufgE2K xR91ibWXhu2Ahw9uKjN43u4pZd5iNA9o18SGlkSwNtU8UMGgWyiXFMiE92VoY+2GrIDT 40pcvLsMazm5+F3b4eeHjkTvuTsVGLdxiGHnaocqUCXjzHXgkQy8JLHSHolZNC40kkoh rSzy7toQNXV0KezYwmGN0CngvzVfXj2oXEFTCPG+BlDiv8lBu9ikDLLDKvwZoNpFTQP/ 1zlQ== X-Gm-Message-State: AOJu0YxVH1aO94FkozWuNuXMzmJICQKmtbsXH7E4ryCbok0Lu7wKzLEV Z92X51J0OB95gPlWXJG1cnXhEMyhdQc= X-Google-Smtp-Source: AGHT+IG/a6Sj0mASs5/8PEJQnR69sSphX+9SHKWYEjRPOLGEF4l6c52AgzjYtmdhHr7JL68mzkGP7JI8NEg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:168c:b0:da0:3e46:8ba5 with SMTP id bx12-20020a056902168c00b00da03e468ba5mr304342ybb.8.1698860209654; Wed, 01 Nov 2023 10:36:49 -0700 (PDT) Date: Wed, 1 Nov 2023 10:36:48 -0700 In-Reply-To: <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Message-ID: Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Kai Huang Cc: "viro@zeniv.linux.org.uk" , "aou@eecs.berkeley.edu" , "brauner@kernel.org" , "oliver.upton@linux.dev" , "chenhuacai@kernel.org" , "paul.walmsley@sifive.com" , "palmer@dabbelt.com" , "maz@kernel.org" , "pbonzini@redhat.com" , "mpe@ellerman.id.au" , "willy@infradead.org" , "anup@brainfault.org" , "akpm@linux-foundation.org" , Xiaoyao Li , "kvm-riscv@lists.infradead.org" , "mic@digikod.net" , "liam.merwick@oracle.com" , "kvm@vger.kernel.org" , Isaku Yamahata , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "tabba@google.com" , "amoorthy@google.com" , "linuxppc-dev@lists.ozlabs.org" , "michael.roth@amd.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "chao.p.peng@linux.intel.com" , "linux-mips@vger.kernel.org" , Vishal Annapurve , "vbabka@suse.cz" , "mail@maciej.szmigiero.name" , "yu.c.zhang@linux.intel.com" , "qperret@google.com" , "dmatlack@google.com" , Yilun Xu , "isaku.yamahata@gmail.com" , "ackerleytng@google.com" , "jarkko@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Wei W Wang X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231101_103653_101470_B83919FC X-CRM114-Status: GOOD ( 20.90 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Wed, Nov 01, 2023, Kai Huang wrote: > > > +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. > > IIUC returning -EFAULT or whatever -errno is sort of KVM internal > implementation. The errno that is returned to userspace is ABI. In KVM, it's a _very_ poorly defined ABI for the vast majority of ioctls(), but it's still technically ABI. KVM gets away with being cavalier with errno because the vast majority of errors are considered fatal by userespace, i.e. in most cases, userspace simply doesn't care about the exact errno. A good example is KVM_RUN with -EINTR; if KVM were to return something other than -EINTR on a pending signal or vcpu->run->immediate_exit, userspace would fall over. > Is it better to relax the validity of kvm_run.memory_fault when > KVM_RUN returns any -errno? Not unless there's a need to do so, and if there is then we can update the documentation accordingly. If KVM's ABI is that kvm_run.memory_fault is valid for any errno, then KVM would need to purge kvm_run.exit_reason super early in KVM_RUN, e.g. to prevent an -EINTR return due to immediate_exit from being misinterpreted as KVM_EXIT_MEMORY_FAULT. And purging exit_reason super early is subtly tricky because KVM's (again, poorly documented) ABI is that *some* exit reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a pending signal). https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > [...] > > > > --- 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; > > +} > > + > > KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to > ? I'd prefer to keep it in generic code, as it's highly likely to end up there sooner than later. There's a known use case for ARM (exit to userspace on missing userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API. [*] https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy@google.com _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 54579C4332F for ; Wed, 1 Nov 2023 17:37:48 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=KF63XbBN; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4SLDjk4Wblz3cYj for ; Thu, 2 Nov 2023 04:37:46 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=KF63XbBN; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::b4a; helo=mail-yb1-xb4a.google.com; envelope-from=3syxczqykdayykgtpimuumrk.iusrot03vvi-jk1royzy.u5rghy.uxm@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4SLDhk2DqDz2xqH for ; Thu, 2 Nov 2023 04:36:52 +1100 (AEDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-da03ef6fc30so5047276.0 for ; Wed, 01 Nov 2023 10:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698860210; x=1699465010; darn=lists.ozlabs.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=KF63XbBNyBeFoxA9ahqEkDM2XPg7vs3nkktkVRtyAScvCj4RBMgzGNqKbq/LJeuquC pmNjssciaOSs659CT4IYAtg11oclMCNcaCiCGE+K07dNuGgcEZ+Ouo7KAOTDSCTn//o3 uDRBhP4nVp8WPlMso6uNqoKaQwhdPC6nscVJRW+3NIGtFWcSZK7d89PPS3sxoYJ/5wew u05tzgez0I5uXp+4T5NkqiXLyV6702DnJDOrf1N1XvkCTF2g6wRyBeMujy15Drg+SfG3 81KwT3Jo7KAn9EJHDUxEGpw/LnrjeokOdhQgUwD3BMfpUkNZQWp6rcnfRWREcqu/ECFc 9RRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698860210; x=1699465010; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=Z5dYE2pgIaby9F8Adb92QlAAggtCVQgcwtVvr5eA1jlBsel5cabfqTv/1jyJbLn89/ xmVwWGPdZG//Zdq7SWfa4OqIrhJFoP0rd5fmI6sEOHB3u3zJxGejJbuomjfAYLOj79BL u/+MKL9goTaobcroPpK8tOhXJBlqp3MRohzb6BXwyYRcrikvvDL/C+nn3G37fogy0zb2 jauJlS6NMSYzvgNkItuWr7/lWw5gdaY9CL93Pt81zhTOj/VSKVnKiSfi9Axqv9SVRiW8 HE/cH2SGLWVS1J/llnWOzbYuhAS0bv+aXM2vEkNMnYU7N4lZXMp86VXYIqlOuWq+RvsL Gfpg== X-Gm-Message-State: AOJu0YykZfjrF9/sBvb2CjN6gOLZv25R4VATWRb1gpgLY9wPYRvZMjaN pJyPTYHulmFjCQhWtHSGSXgQfWYKDp0= X-Google-Smtp-Source: AGHT+IG/a6Sj0mASs5/8PEJQnR69sSphX+9SHKWYEjRPOLGEF4l6c52AgzjYtmdhHr7JL68mzkGP7JI8NEg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:168c:b0:da0:3e46:8ba5 with SMTP id bx12-20020a056902168c00b00da03e468ba5mr304342ybb.8.1698860209654; Wed, 01 Nov 2023 10:36:49 -0700 (PDT) Date: Wed, 1 Nov 2023 10:36:48 -0700 In-Reply-To: <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Message-ID: Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Kai Huang Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "kvm@vger.kernel.org" , "david@redhat.com" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "kvmarm@lists.linux.dev" , "pbonzini@redhat.com" , "chao.p.peng@linux.intel.com" , "linux-riscv@lists.infradead.org" , "isaku.yamahata@gmail.com" , "chenhuacai@kernel.org" , Xiaoyao Li , "willy@infradead.org" , Wei W Wang , "vbabka@suse.cz" , "yu.c.zhang@linux.intel.com" , "linux-arm-kernel@lists.infradead.org" , "mail@maciej.szmigiero.name" , "aou@eecs.berkeley.edu" , "michael.roth@amd.com" , "ackerleytng@google.com" , "viro@zeniv.linux.org.uk" , "paul.walmsley@sifive.com" , "mic@digikod.net" , "tabba@google.com" , Isaku Yamahata , "brauner@kernel.org" , "qperret@google.com" , "anup@brainfault.org" , "linux-kernel@vger.kernel.org" , "oliver.upton@linux.dev" , "dmatlack@google.com" , "jarkko@kernel.org" , "palmer@dabbelt.com" , "amoorthy@google.com" , "kvm-riscv@lists.infradead.org" , "maz@kernel.org" , "linux-fsdevel@vger.kernel.org" , "liam.merwick@oracle.com" , "akpm@linux-foundation.org" , Vishal Annapurve , "linuxppc-dev@list s.ozlabs.org" , Yilun Xu , "kirill.shutemov@linux.intel.com" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Nov 01, 2023, Kai Huang wrote: > > > +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. > > IIUC returning -EFAULT or whatever -errno is sort of KVM internal > implementation. The errno that is returned to userspace is ABI. In KVM, it's a _very_ poorly defined ABI for the vast majority of ioctls(), but it's still technically ABI. KVM gets away with being cavalier with errno because the vast majority of errors are considered fatal by userespace, i.e. in most cases, userspace simply doesn't care about the exact errno. A good example is KVM_RUN with -EINTR; if KVM were to return something other than -EINTR on a pending signal or vcpu->run->immediate_exit, userspace would fall over. > Is it better to relax the validity of kvm_run.memory_fault when > KVM_RUN returns any -errno? Not unless there's a need to do so, and if there is then we can update the documentation accordingly. If KVM's ABI is that kvm_run.memory_fault is valid for any errno, then KVM would need to purge kvm_run.exit_reason super early in KVM_RUN, e.g. to prevent an -EINTR return due to immediate_exit from being misinterpreted as KVM_EXIT_MEMORY_FAULT. And purging exit_reason super early is subtly tricky because KVM's (again, poorly documented) ABI is that *some* exit reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a pending signal). https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > [...] > > > > --- 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; > > +} > > + > > KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to > ? I'd prefer to keep it in generic code, as it's highly likely to end up there sooner than later. There's a known use case for ARM (exit to userspace on missing userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API. [*] https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy@google.com 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3DAE6C4167D for ; Wed, 1 Nov 2023 17:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=s8pZKc5dMeeFUfS/fStVaCDvHNXVyO86kUEB8hXbQ/k=; b=aJBGC1+8o5zCVFCEVyXxxHuO6B QtcRxlWoOOq7eTCfkLHY7mZ4Ki+Bf8ADTUJTRyaRBBN5nIoDUL0cDUT75UQlrrq56D9DMAWj5X6mB VubEU32A6+3Yf7hV52JQHnIBzIkLrnkwKu+/z3TS48fTtq02H8LfUY4XXeX+yDLS3tAS/pmICfIHz IPD7uw6+ZVdIzfDoK6fPrvfvLlTD6jkxBk7itY09nf7wID7o3ktUG1qoofrEMkS61Mf5TqExPCjcz 1gLFIUGW+IRZb67sUBq5f3HfmLeuQUpudRYzrujwgzsU+0gPsK6Jb6kGj/lkNAY7FZDeO7jqvRcJO liWSlaYQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qyF9H-007t5e-1g; Wed, 01 Nov 2023 17:36:59 +0000 Received: from mail-yb1-xb49.google.com ([2607:f8b0:4864:20::b49]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qyF9E-007t2j-1A for linux-arm-kernel@lists.infradead.org; Wed, 01 Nov 2023 17:36:57 +0000 Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-da03ef6fc30so5044276.0 for ; Wed, 01 Nov 2023 10:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698860209; x=1699465009; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=fsWpC2RbvONMs14YuuPPJ87cpSMciGnAp3NRcfWv9OyXeXZNvgSWupK0xUpWdyxBGo N36noxpgT0QR315yX3qcrTr/jpAvzd38Y4hKG1B7cXvQwPNpDcjZsnMdLTM7Yk2mPRK1 JK6ldkc2i95VZ1lvxkzRwxnwkdZ+7zQrfhbe3+gc5qJw0u3TDX7WZD34Da1xbDDlergl Or/4zGeuB3YBczWd975+NLs/f0dZGC0E2dDkBrvM4MoGUGas+B9oJZlhILEjU98M+Beo 7Q0dglUyPstrdb6sMJ2wL+BAtbbcbVX/TTN/kXgZ/881m4bNSO4snBvlaj8QSzEUD+Ep 3nLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698860209; x=1699465009; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=Sj3YviNfdUOdjCRGWQQfl3d5fKtrJElmsQi7x/oQcV7ZKtSbh/ZRh9cXUlBseNKt/A ETi6QrAFuQJk/Lc39+WIVeKOQk/DUE2N5WbfNPi4cKeFyR2co/R6UmVVU4JdVvRrhZsQ DfQTQpgs1xHNGKVow9Rh0pLZu6I2wHjmfabRGa56apdk/9kOPfp118UhYUUga8dmnT6J Jtt67pK3Xted6RuYDKXetRld4gvsgn3y1IODPf1grY6P7piPql1X7GmqzveDZjHyVuYL fb8/UmjJfUDgZ26SeQkd/b5t8jUuZoB2CUi8jURjsS4MmEaot7mUZWaxg4moSuGnZ0Ng y4Mg== X-Gm-Message-State: AOJu0YwP7RWkP+kCCXsg+M1hq1JeXULFrgNhKZNATPT5Ya9JG6fVd0d8 UemqXNG6NHfFtg4LHTnFruChS5EK+nw= X-Google-Smtp-Source: AGHT+IG/a6Sj0mASs5/8PEJQnR69sSphX+9SHKWYEjRPOLGEF4l6c52AgzjYtmdhHr7JL68mzkGP7JI8NEg= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:168c:b0:da0:3e46:8ba5 with SMTP id bx12-20020a056902168c00b00da03e468ba5mr304342ybb.8.1698860209654; Wed, 01 Nov 2023 10:36:49 -0700 (PDT) Date: Wed, 1 Nov 2023 10:36:48 -0700 In-Reply-To: <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-10-seanjc@google.com> <482bfea6f54ea1bb7d1ad75e03541d0ba0e5be6f.camel@intel.com> Message-ID: Subject: Re: [PATCH v13 09/35] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Kai Huang Cc: "viro@zeniv.linux.org.uk" , "aou@eecs.berkeley.edu" , "brauner@kernel.org" , "oliver.upton@linux.dev" , "chenhuacai@kernel.org" , "paul.walmsley@sifive.com" , "palmer@dabbelt.com" , "maz@kernel.org" , "pbonzini@redhat.com" , "mpe@ellerman.id.au" , "willy@infradead.org" , "anup@brainfault.org" , "akpm@linux-foundation.org" , Xiaoyao Li , "kvm-riscv@lists.infradead.org" , "mic@digikod.net" , "liam.merwick@oracle.com" , "kvm@vger.kernel.org" , Isaku Yamahata , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "tabba@google.com" , "amoorthy@google.com" , "linuxppc-dev@lists.ozlabs.org" , "michael.roth@amd.com" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "chao.p.peng@linux.intel.com" , "linux-mips@vger.kernel.org" , Vishal Annapurve , "vbabka@suse.cz" , "mail@maciej.szmigiero.name" , "yu.c.zhang@linux.intel.com" , "qperret@google.com" , "dmatlack@google.com" , Yilun Xu , "isaku.yamahata@gmail.com" , "ackerleytng@google.com" , "jarkko@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mm@kvack.org" , Wei W Wang X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231101_103656_402732_5F84C97B X-CRM114-Status: GOOD ( 22.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 01, 2023, Kai Huang wrote: > > > +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. > > IIUC returning -EFAULT or whatever -errno is sort of KVM internal > implementation. The errno that is returned to userspace is ABI. In KVM, it's a _very_ poorly defined ABI for the vast majority of ioctls(), but it's still technically ABI. KVM gets away with being cavalier with errno because the vast majority of errors are considered fatal by userespace, i.e. in most cases, userspace simply doesn't care about the exact errno. A good example is KVM_RUN with -EINTR; if KVM were to return something other than -EINTR on a pending signal or vcpu->run->immediate_exit, userspace would fall over. > Is it better to relax the validity of kvm_run.memory_fault when > KVM_RUN returns any -errno? Not unless there's a need to do so, and if there is then we can update the documentation accordingly. If KVM's ABI is that kvm_run.memory_fault is valid for any errno, then KVM would need to purge kvm_run.exit_reason super early in KVM_RUN, e.g. to prevent an -EINTR return due to immediate_exit from being misinterpreted as KVM_EXIT_MEMORY_FAULT. And purging exit_reason super early is subtly tricky because KVM's (again, poorly documented) ABI is that *some* exit reasons are preserved across KVM_RUN with vcpu->run->immediate_exit (or with a pending signal). https://lore.kernel.org/all/ZFFbwOXZ5uI%2Fgdaf@google.com > [...] > > > > --- 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; > > +} > > + > > KVM_CAP_MEMORY_FAULT_INFO is x86 only, is it better to put this function to > ? I'd prefer to keep it in generic code, as it's highly likely to end up there sooner than later. There's a known use case for ARM (exit to userspace on missing userspace mapping[*]), and I'm guessing pKVM (also ARM) will also utilize this API. [*] https://lore.kernel.org/all/20230908222905.1321305-8-amoorthy@google.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel