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 EA6F6C04A95 for ; Tue, 25 Oct 2022 16:17:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 607D08E0002; Tue, 25 Oct 2022 12:17:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 590828E0001; Tue, 25 Oct 2022 12:17:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 431418E0002; Tue, 25 Oct 2022 12:17:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2D5068E0001 for ; Tue, 25 Oct 2022 12:17:36 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 02CF11401D6 for ; Tue, 25 Oct 2022 16:17:35 +0000 (UTC) X-FDA: 80059977312.24.BB66E0B Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by imf07.hostedemail.com (Postfix) with ESMTP id 9DEE14001A for ; Tue, 25 Oct 2022 16:17:35 +0000 (UTC) Received: by mail-pj1-f41.google.com with SMTP id h14so11315314pjv.4 for ; Tue, 25 Oct 2022 09:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0XpehjN5/x0DVN6iNfQRcpwLRiHoknqSMi2DnBppXC4=; b=VTegWoMotPt2w65LyX5l1RfBFsrVct34KfNYTQclV1Ej8EpD0Aka6DhRqFqKKPkKYF dx/pMAu3a28hbLyvQafo+3Wa+3mCeMIJhF5AVwXriBoAuAKBIFTkfyEZGt3R9F9Nhi41 fj+nZajeXUNM6G2OtS9Tq69y8zmBsHay0qJIu6C8XDsQnxvChs2zKzG+iHzQM3CemyK7 rQ1rbv2xpfwgbK/hJO81F9yW0YMzSmbw6UXv81EZOUicFWm2Vd2NYV/mOhEHD+opJjML IMkSJQctzTXXbBbp4cSFHMIFqYkomesQTa0hCcAW0LxBYbC7hn0bynG64p0PfcuPbXmb uofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0XpehjN5/x0DVN6iNfQRcpwLRiHoknqSMi2DnBppXC4=; b=BN0iX+/PC3Y70A5AYLLDGm1ZGWLSMvuWNVTwzhTt83dNiw2YMb2t1FhANc697MxR9Z PHeSqlaU8ilb71OCgUWFzIw6/p5TAbbHslPPXRcMDpnlmEBHBSTHlDs7y3bzkANdznVQ mwt/F19sUsA9I5sVu2gJoiVJnPqqv3KsO231EDGq9Hk7r5cHPXuTj/qBb5apk3yKMnzx BwmFy45bYsewVE71lcEkzidGrExiqRZ2fxH0OIcRulifrIByH7/M7ONVg6FsmuuHgstr zIb2E/AQthQD9RSUX+MH/hoeWNO/0IJs8buP//94quyaB5k+2Uf4rxXW0fn7KZlnkLAe 4ntg== X-Gm-Message-State: ACrzQf0wgmrdrK3AuYCjOwWiZO74sf4I+he8X11EuDVF/GV/nQCMNZaK zjY4VtgU0gaenD1Ss8BxllPm0g== X-Google-Smtp-Source: AMsMyM738RdpBPHm9pvc30fi3c2/lYdgFkQc2nwAzBbq52uGbxkdpRe8GUTzQNa3Uoldv8m3HWsH3Q== X-Received: by 2002:a17:903:41c7:b0:182:a32f:4db5 with SMTP id u7-20020a17090341c700b00182a32f4db5mr39384792ple.22.1666714654279; Tue, 25 Oct 2022 09:17:34 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id b3-20020a1709027e0300b00186881e1feasm1399643plm.112.2022.10.25.09.17.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Oct 2022 09:17:33 -0700 (PDT) Date: Tue, 25 Oct 2022 16:17:30 +0000 From: Sean Christopherson To: Peter Maydell Cc: Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "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" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit Message-ID: References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <20221025151344.3784230-4-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666714655; a=rsa-sha256; cv=none; b=of2743w6YtftILk2BMcKmoEjwURIB3wLfiuG7ztaYYnPM0nT1FhDQaCpxqMBxnKbarfWSO BrNl0ZX5GNqUbQWLJj3HxwMaKiorQeL2jcyKYZ0YTThXond0KG0rIchEy8CmQqX1vrJjrX gzVjwMH2/C31hEBI79KzN44q9QehNtw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VTegWoMo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of seanjc@google.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=seanjc@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666714655; 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=0XpehjN5/x0DVN6iNfQRcpwLRiHoknqSMi2DnBppXC4=; b=av/6OlOU95Vlw6J3p93ZVWyi4KVLrre6AchTdLYiqUy4vAVUXRuAPRxousl6SczCFnQs4z KCtZawoPq5whypQo9L0ZOph9za9J4JSf0y5Bj3DW5z9Dtg5O84/LYVBU2ZuRCNtSQzLZ7Q kROZuSGVWsaf8dV9A/2u8/65ZnesfXg= X-Stat-Signature: jectcxjfhqy8xd8jzwf9fe91bu6pzxem X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9DEE14001A Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VTegWoMo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of seanjc@google.com designates 209.85.216.41 as permitted sender) smtp.mailfrom=seanjc@google.com X-HE-Tag: 1666714655-488931 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, Peter Maydell wrote: > On Tue, 25 Oct 2022 at 16:21, Chao Peng wrote: > > 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; > > + > > +If exit reason is KVM_EXIT_MEMORY_FAULT then it indicates that the VCPU has > > +encountered a memory error which is not handled by KVM kernel module and > > +userspace may choose to handle it. The 'flags' field indicates the memory > > +properties of the exit. > > + > > + - KVM_MEMORY_EXIT_FLAG_PRIVATE - indicates the memory error is caused by > > + private memory access when the bit is set. Otherwise the memory error is > > + caused by shared memory access when the bit is clear. > > + > > +'gpa' and 'size' indicate the memory range the error occurs at. The userspace > > +may handle the error and return to KVM to retry the previous memory access. > > + > > What's the difference between this and a plain old MMIO exit ? > Just that we can specify a wider size and some flags ? KVM_EXIT_MMIO is purely for cases where there is no memslot. KVM_EXIT_MEMORY_FAULT will be used for scenarios where there is a valid memslot for a GPA, but for whatever reason KVM cannot map the memslot into the guest. In this series, the new exit type is use to handle guest-initiated conversions between shared and private memory. By design, conversion requires explicit action from userspace, and so even though KVM has a valid memslot, KVM needs to exit to userspace to effectively forward the conversion request to userspace. Long term, I also hope to convert all guest-triggered -EFAULT paths to instead return KVM_EXIT_MEMORY_FAULT. At minimum, returning KVM_EXIT_MEMORY_FAULT instead of -EFAULT will allow KVM to provide userspace with the "bad" GPA when something goes sideways, e.g. if faulting in the page failed because there's no valid userspace mapping. There have also been two potential use cases[1][2], though they both appear to have been abandoned, where userspace would do something more than just kill the guest in response to KVM_EXIT_MEMORY_FAULT. [1] https://lkml.kernel.org/r/20200617230052.GB27751@linux.intel.com [2] https://lore.kernel.org/all/YKxJLcg%2FWomPE422@google.com