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 B609CC4332F for ; Wed, 1 Nov 2023 17:36:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 392EA6B029A; Wed, 1 Nov 2023 13:36:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31B6D6B029B; Wed, 1 Nov 2023 13:36:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BB976B029D; Wed, 1 Nov 2023 13:36:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 060696B029A for ; Wed, 1 Nov 2023 13:36:53 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A0890B5EAD for ; Wed, 1 Nov 2023 17:36:52 +0000 (UTC) X-FDA: 81410090664.06.F56DB9A Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf23.hostedemail.com (Postfix) with ESMTP id A8336140024 for ; Wed, 1 Nov 2023 17:36:50 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vJ7pvi11; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of 3sYxCZQYKCAYykgtpimuumrk.iusrot03-ssq1giq.uxm@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3sYxCZQYKCAYykgtpimuumrk.iusrot03-ssq1giq.uxm@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698860210; 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=Aa5pPv4/g+I3C3eNDgudVhrFstr6S8Xmtwrf0OlljDI=; b=oVBrpIgE7R2e5dTQ/kBZYPDyq1KuCoRkFbeULFhYnBGeQI7RtNOJvp3RaCfu8S/mLnj7zr 2b1YdA4Dxq147czcxZiQYd8u8e7Dewtm0gdbZz5TiWlPsHhCK0S+CL03+fqRKq45Mt9a19 /aqbFzuB9XjyvMux+v+lk4DPmfEJN/A= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vJ7pvi11; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of 3sYxCZQYKCAYykgtpimuumrk.iusrot03-ssq1giq.uxm@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3sYxCZQYKCAYykgtpimuumrk.iusrot03-ssq1giq.uxm@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698860210; a=rsa-sha256; cv=none; b=8PkNRkTm1IhCsgnPdYygMQebC4awsV0NDTKXFKOXoy63IDvAPn8UTyACyTuk0ez9lS5Ad9 ckXnhkCQXSmNrsVH/rxh60zgSCVgb9gaff9xOilCbaLd088hqi6lvl5jGo2PBEuj+WDpv3 iyq7jVzjuFI97V2WSm2c+ahIgeqwj3g= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-da0c7d27fb0so6524152276.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=kvack.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=vJ7pvi11NZP+SjC/18X4ytqkbgAs03CJDAQN6VRuBEXHZaDZnBMfi57XHAmszqFcKC /GdWPc+5ulmyB0aist72JoyVRi0nNQW69oPP6xntYqKyeU70hFGEgjcp6iQrc64JzP2C q7gtCYYCmBj5xQJYKHdrgmDIdzF2Os27sqDeLWui10vEjIV8QxXZNlo2cElq7LGYpU0p YywDXgbIAAv6+Wqzqp9h81jS9iT3LcOBRB/UAIndTS/+8xikXI+vPtBpVCUX7aT9I1Wr 5Cx3TgaE5Eos990iU39u4ybWVcWZj2/EXF9WZUErG5jVAJRuYV9VE7e8Ttb1sV2j8c8T CWyw== 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=p/7wpFTTCnOC8lxVMfn/QRPdIh3r5m2TuwrL+RRGQ9cnlZLyB6/GVamDwvJmOmT+85 iH8DDgfP+/RKij/PzATNXVAy4eK9ZRNLJ9MrwJPIs96YBkETg+PUp9xgLTErt1Qp+jNi v7O/gQbHsNbaLBhofFfSyaXQk0CapIGdP9DB7W91U6vJIQoOJrYoqgHsuovQ6CTll8wb R1EqHeCKY46XSecPXF1oHyRpt7Kc8zdiIbgH9mF+YD79owpN7D1TXzI6sT3DFnL1MUdJ BfZJYdTjXk2+JytT3qSEr+j2r3hGDkPj0jqk57cYWA76Ue3OX70aJCLHkm8yqE79S3G4 +rOA== X-Gm-Message-State: AOJu0YxASoBIpsHxqNSBEs0ScduZMELJ6BoR7v8/JZp+Zb5lOwMZwKQ5 Wou4PnNOFQ0w+tMao1oKQvIi7D1KZBo= 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 Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: A8336140024 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: axpme1z6hxdo5arjt9qy4oqfhpd4joqw X-HE-Tag: 1698860210-205056 X-HE-Meta: U2FsdGVkX1+3bPa3WCyIHBvf5T9LP8PN11VmqhjF0At0Fmz5531RyKdjJvjqmKOg6Y769Dz6q7u6Uh4HfCJw+cHn8vUcpLAupfSeJxyVg/oXkILZNhHNs7qE7Mj0Sf3gKLbdOl6KIE/5soIj8AXIakDPf5Gi5NKngGc4BrsRgkaUvP6qIlq30BSSpRkfAmLNOrZ2rjK79LgqP91IGCJl/2kOSRDZJPz9XRUhUVbJ0qZch39o7DoJFxDht4bU6QSGfIVwQb4PgUhKcIzBshSKIoSV9DRJFgBls7rSMQ+/heyXFM9dmaTobpBZirVl1DMvgM5aQ6q5rCvVR81ycA6EsQroc2bt6JSMSZIkJY6o6VktdcQp/7h8GmaQVW3IvnO/kX4u5IEfps5k/wbyVOyZqBDSxagSxbnmKEfNyQxPs7gRHUEfgn4UyKD7i++Pj75ZqoZCjODayUd7OS2Sn2jumRYlqsVDPhPA8gHgTEp8aNSairHtAYZppRF+zhTAFnR6K2TGzUthGw5Fb3djBDK/6RyDcPNJoI4QEVLObO8RRFSanYXRXAqYkWzesTOZT9VozTcDCZb8KaR9nb+2whhaixeTOOrtRUTRCf7umFqFMZGXpsaKVdws/bushkkPsdbwbhJ7H+6y/T0LS3OCbnj36PfJyrULTGy9+78whEyCorddzS7TJTiVqYfx1eFf2WjC1yXcynCWma2gk5x6hdZegg//IEFsMT+4eKAUITm3PQlBxQRD6+1NDVjVFrY6fWuTx6Liwx6EeT/w5Dy7RP7jp1hIgt0X+pzzKqooKB2o2me6BS3Mrjvvvya/rb3xnF6USX+Vl/ZdfwzNSww3TMOnHSSHwqDsBW/cEQfsgq4UbCKy05Doo3EdsZb7BmydyjkTgnzA5uaSQAhPs+x56wFAeXoRnqyJH26f+JLG6VZ0axuC9U2oN3cgBarI+7V0LoJDGETP7oZBPWeNjgGa6lJ qJJKr05z Jw23OJrReYss5p9iIC0PGmmmCl9t9X6IOiSmM2+wHwvD8P5V1dOSEhXuRuR48QX3Vztv9yhgjfWucNL2gciYzSkplbneNkSjbTti2TrGf+YJ+hFflkUt5uxebuVX8TyQJFTDwQsaX7N7M7elmR3uh2RsdLVi6xQ/0x7sDOmwtVl8mG4KsNmoFDrlZWDd22h3PchJXOctXqMB64xNCEKvXq6KvYvn4x0YabjnsFzBdC1MIKJmvdUn6PGd1VOplr8cBST98Gogu6HGeL0MnPWukPJQgAdIyBvT4dHPtH0ZWsrYVrpLlXhOky5DOqSp8O/kz7oHVDVIJiPwDmnjV8Cwh4FOP59eZm5XKJLo430SsidXqgTeozx8CBSMnSoDrjHETJzcvf7OJFKV/DfEtXImSRqAgNa/O5xgN52L28tKAkyW82IqQNLrMPOCLSYWLAZOUNC6GP3EQQ8OhsdwgC1upfkVqdKIzowbcyN79lp9EqKoim9bfyi/SEZIziHRMds/mAWuTd/tN3UX4QpOMwzffCRn0c9Zh+5jWMHvssiCViyOZQoyI4TqGI7Tgx08VL48aPudHkGd66/hkfNjMt50MaaKVtbkem+IA9BoksIkTUBgyETOh3guIzLPzEGigL9nEKPlLiQv3Vo8A+NaKe3+bilFmhy7jH2+XjP1Jhq25TjSUAV4ccYzsuV61T7Ti9gqTUuPcJsN4mhjyMai0+cdm9nz9YbZywX/IdjCbwI4QlccmKSuspzM8jKi6ftneS1acU8t4a+ihzNLoU9/Ng4+5oJ/gn9TWHjo4MyyrlXaIl7scUD3aeht2miR2KRXBEq3lFL0o X-Bogosity: Ham, tests=bogofilter, spamicity=0.001277, 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 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