From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 22 Sep 2023 07:30:38 -0700 Subject: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace In-Reply-To: <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-8-seanjc@google.com> <117db856-9aec-e91c-b1d4-db2b90ae563d@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 Fri, Sep 22, 2023, Xiaoyao Li wrote: > On 9/14/2023 9:55 AM, 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, > > side topic. > > Do we expect to integrate TDVMCALL(MAPGPA) of TDX into KVM_HC_MAP_GPA_RANGE? Yes, that's my expectation. > > 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. > > > > Place "struct memory_fault" in a second anonymous union so that filling > > memory_fault doesn't clobber state from other yet-to-be-fulfilled exits, > > and to provide additional information if KVM does NOT ultimately exit to > > userspace with KVM_EXIT_MEMORY_FAULT, e.g. if KVM suppresses (or worse, > > loses) the exit, as KVM often suppresses exits for memory failures that > > occur when accessing paravirt data structures. The initial usage for > > private memory will be all-or-nothing, but other features such as the > > proposed "userfault on missing mappings" support will use > > KVM_EXIT_MEMORY_FAULT for potentially _all_ guest memory accesses, i.e. > > will run afoul of KVM's various quirks. > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > the first union is valid? > > When exit reason is not KVM_EXIT_MEMORY_FAULT, how can we know the info in > the second union run.memory is valid without a run.memory.valid field? I'll respond to this separately with a trimmed Cc list. I suspect this will be a rather lengthy conversation, and it has almost nothing to do with guest_memfd. > > +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. > > + > > Initially, this section is the copy of struct kvm_run and had comments for > each field accordingly. Unfortunately, the consistence has not been well > maintained during the new filed being added. > > Do we expect to fix it? AFAIK, no one is working on cleaning up this section of the docs, but as always, patches are welcome :-) From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.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 8066A3D969 for ; Fri, 22 Sep 2023 14:30:40 +0000 (UTC) Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-1c5b1e55d5eso17607985ad.3 for ; Fri, 22 Sep 2023 07:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=OMyQFipCJiV6Xq/uU2WmtGADCGJ+6DZsUvfy2OaVpPGlxAPHSHX5WuKGG0v7kpHOiW K9U0apBB6+uwQdaCsBecpFM7sZD7KHM1u7UiqKp5/fshraSbS7eZwSiHEwmeb+g0dYxu XnkASUlffNWB9EJbh3hDst/eanc+EpPwEOjOm3hPXL7lveIDITm5SWl0fg3vyBeUVbde 9m1iTZKN7ehhQ44oiJw9k9X9OCIpb7Z+Y8aiKRKukVOHjkx6j7GiBJPNWaiIhctY5xXB NaDA4vN3TrE3BXAGeqlPVsQN7fWKLf99jIX1ISF83gmmCb+bdOOceASVLjByneaJCUHN LdOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=i9R8nm2q2GygFgo3oSW6GVdlX3MsuPInaJQF2lA6Y8SBjU0ntrQGSjQ9Yu99JEUN0J u3OiiJs7q9sKw0v+BO3H9hVU+dKoFfZkHJ5655XKaWFiZVWRIN4CXdcYxtcckXpfPfBH mDyqIlYjZd/qzUksRupRm30fe5BAAelcZY3F9ILIxtLy+vBjPYUm5saCOOwJM84Qeiun xXIDm0zBu56hMdmlOsZIgHbHyWY2hPEKQfqPhx2In8YE5Rchqa5hoIlRfa8V9Mc0s9y3 3PJ+5KXO3FEWgK2h7M0ZMuX0DfJylOo3vw25veKjUz/13CaT8RfJUWuX5oe3KYVBVtYA 3pzw== X-Gm-Message-State: AOJu0Yync0Y+BNxgvxzyO2omETHsEVb0OXbgE77Fvc4ZTHmQHX21ZNQ/ 6Y0z4xQaIVV4jzfLxb3hapJhzrXoG0A= X-Google-Smtp-Source: AGHT+IE7TdAMSox3QZ9i3XY42vmW+YqwJtHLDXCrkzOQDSyIHqr/K/m4w9DaaKuedrPKXRX2zXN/sfp+lRA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:1cf:b0:1b9:df8f:888c with SMTP id e15-20020a17090301cf00b001b9df8f888cmr102903plh.8.1695393039713; Fri, 22 Sep 2023 07:30:39 -0700 (PDT) Date: Fri, 22 Sep 2023 07:30:38 -0700 In-Reply-To: <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-8-seanjc@google.com> <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Message-ID: Subject: Re: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Xiaoyao Li Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , 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-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , 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="us-ascii" On Fri, Sep 22, 2023, Xiaoyao Li wrote: > On 9/14/2023 9:55 AM, 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, > > side topic. > > Do we expect to integrate TDVMCALL(MAPGPA) of TDX into KVM_HC_MAP_GPA_RANGE? Yes, that's my expectation. > > 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. > > > > Place "struct memory_fault" in a second anonymous union so that filling > > memory_fault doesn't clobber state from other yet-to-be-fulfilled exits, > > and to provide additional information if KVM does NOT ultimately exit to > > userspace with KVM_EXIT_MEMORY_FAULT, e.g. if KVM suppresses (or worse, > > loses) the exit, as KVM often suppresses exits for memory failures that > > occur when accessing paravirt data structures. The initial usage for > > private memory will be all-or-nothing, but other features such as the > > proposed "userfault on missing mappings" support will use > > KVM_EXIT_MEMORY_FAULT for potentially _all_ guest memory accesses, i.e. > > will run afoul of KVM's various quirks. > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > the first union is valid? > > When exit reason is not KVM_EXIT_MEMORY_FAULT, how can we know the info in > the second union run.memory is valid without a run.memory.valid field? I'll respond to this separately with a trimmed Cc list. I suspect this will be a rather lengthy conversation, and it has almost nothing to do with guest_memfd. > > +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. > > + > > Initially, this section is the copy of struct kvm_run and had comments for > each field accordingly. Unfortunately, the consistence has not been well > maintained during the new filed being added. > > Do we expect to fix it? AFAIK, no one is working on cleaning up this section of the docs, but as always, patches are welcome :-) 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 48058E6FE38 for ; Fri, 22 Sep 2023 14:31:02 +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=l8VmnbGGe1p664P6PyEtkQdQDP0EB6IiIJ96/dGiTmc=; b=fmii43GwaJqGm21NscSW35xC5e jwy/kAVNkl+1ObxVvPVEdfx613VuoyVsqrEwGkaySBPKt9Vgzz8zfmpZgWn0kT+lcx/fDC96s5F1M Y4/tLgJVjHARqNdSUGCf1DcfT2HqRHoauc55vIHBkF+Z+mcm7AoIzqJ+OSPg3NLGXwSxWI2XKOLyS 9CrcSL/48wyh+a6uYpHf1lCC6LYdrcOwzN806flIOHDusLn6rPhTshLBwR1NhcUGAeXamYxMoSnky nvb6CC8DsfK4SdJaXjO/APDvwMe/uDuUs0z6QNpAHx47W3+q2gOrsQvxsMKy1qDl79Y1uoPMgDeHs 8RdgkUKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qjhBA-009Clh-1Y; Fri, 22 Sep 2023 14:30:48 +0000 Received: from mail-pl1-x64a.google.com ([2607:f8b0:4864:20::64a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjhB6-009Cij-17 for linux-riscv@lists.infradead.org; Fri, 22 Sep 2023 14:30:46 +0000 Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1c40ac5b6e7so17775105ad.0 for ; Fri, 22 Sep 2023 07:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=oGFdt5ZoSOtfQY/E9eQAlqh6boMh9E/NI0mstDro2N/fEjR2lpRyORybF/OE8vC/0u xybya70aLjhWPyOv3LsOQbHcJ+sq5oIC55IqvSzUv4tkgBdS2oWTE/rpGchmukGn+1Fb G5urGs+JquZJs4VfROrtgt0Bb/STfesPwwD5TygD5C2gz180lHm1kneIzUElFtQ7qETY wFKkqul9rGpi91IAgn9+9OrisB2xzA+oc7Kgc7Q14a7WO+9RfX0x5iyq/PbHqUBReKNe HcR1m0fDVkGm/3b092qm2WVVF1JYjfC4RrACJKJhSfgjvt1VtO1Y2DLI7FzWUeUYMl6R tw6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=aUKFscPmpqtPXq5ieRelpztdv9k6MTwC/QjyRL+1g72Z5OSGMmA6Qb8hlYdqWIxTpD wZ/ujIgIiEti4dUOnS9941Oi0OKoSHR8AMQJPOaDED+StpLHIW62rYQ15/rFEBhCXeIF LKtlXqDEQFdle6BUdjYwAjDaIT2ywWL9QIevdje5ZXABZZdj6cAr84+74hnv5/GOzrev 0DbZMDTKEXgzDjk7l0Lc1VlIFn7ZNstpvOFIBqHUwmJ2mxn3YtZTXTZPuen/o7P0j8ET esYCbD/qrlXWrYAV8acT7t7tF8rjHIDtxV3NV0VqYJ9dWB0KkRqxq7jGdeFNbV9iKUlB 6lmA== X-Gm-Message-State: AOJu0YxcpcSrkz3Q2k4pc0RMjCs/WQe7snV8JI7gvSY/ZLiutbek22UD gV2db+DdK2qltKHTY1ujU5JTnxwAkZo= X-Google-Smtp-Source: AGHT+IE7TdAMSox3QZ9i3XY42vmW+YqwJtHLDXCrkzOQDSyIHqr/K/m4w9DaaKuedrPKXRX2zXN/sfp+lRA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:1cf:b0:1b9:df8f:888c with SMTP id e15-20020a17090301cf00b001b9df8f888cmr102903plh.8.1695393039713; Fri, 22 Sep 2023 07:30:39 -0700 (PDT) Date: Fri, 22 Sep 2023 07:30:38 -0700 In-Reply-To: <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-8-seanjc@google.com> <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Message-ID: Subject: Re: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Xiaoyao Li Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , 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-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230922_073044_387730_C0BD3A41 X-CRM114-Status: GOOD ( 27.89 ) 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 Fri, Sep 22, 2023, Xiaoyao Li wrote: > On 9/14/2023 9:55 AM, 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, > > side topic. > > Do we expect to integrate TDVMCALL(MAPGPA) of TDX into KVM_HC_MAP_GPA_RANGE? Yes, that's my expectation. > > 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. > > > > Place "struct memory_fault" in a second anonymous union so that filling > > memory_fault doesn't clobber state from other yet-to-be-fulfilled exits, > > and to provide additional information if KVM does NOT ultimately exit to > > userspace with KVM_EXIT_MEMORY_FAULT, e.g. if KVM suppresses (or worse, > > loses) the exit, as KVM often suppresses exits for memory failures that > > occur when accessing paravirt data structures. The initial usage for > > private memory will be all-or-nothing, but other features such as the > > proposed "userfault on missing mappings" support will use > > KVM_EXIT_MEMORY_FAULT for potentially _all_ guest memory accesses, i.e. > > will run afoul of KVM's various quirks. > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > the first union is valid? > > When exit reason is not KVM_EXIT_MEMORY_FAULT, how can we know the info in > the second union run.memory is valid without a run.memory.valid field? I'll respond to this separately with a trimmed Cc list. I suspect this will be a rather lengthy conversation, and it has almost nothing to do with guest_memfd. > > +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. > > + > > Initially, this section is the copy of struct kvm_run and had comments for > each field accordingly. Unfortunately, the consistence has not been well > maintained during the new filed being added. > > Do we expect to fix it? AFAIK, no one is working on cleaning up this section of the docs, but as always, patches are welcome :-) _______________________________________________ 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 6A25AE6FE38 for ; Fri, 22 Sep 2023 14:31:39 +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=RH5RhQAG; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RsZTP5Xmjz3cmS for ; Sat, 23 Sep 2023 00:31:37 +1000 (AEST) 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=RH5RhQAG; 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::649; helo=mail-pl1-x649.google.com; envelope-from=3d6unzqykdl4wierngksskpi.gsqpmry1ttg-hizpmwxw.s3pefw.svk@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) (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 4RsZSN2TYjz3cNV for ; Sat, 23 Sep 2023 00:30:42 +1000 (AEST) Received: by mail-pl1-x649.google.com with SMTP id d9443c01a7336-1c40ac5b6e7so17775075ad.0 for ; Fri, 22 Sep 2023 07:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=RH5RhQAG1t6V79vFQ8evay7v83cOPwdLthgeNEoQMqKoQSnEUSg5JFjgtrQgw3Bjku qBhZBukfBeL8QuD1DgocUxz6Cb6AhYDF/34ImFRsjwtCRiBdr44jXFb3jVakxN+/eXEn cg2KTseNljg/wbOby6a/6cMIj7fcz/tg56hXo8k93Y0daICnRTYhrsPyOSlPwuBLQZFZ 3Keh7iSMmtxNI/Ggvpf/r6EeqCea22YxUJqn1iZk06CaOkwl/WuyV9OLFnCsirmEWqlv 57TUmU+0y//X30/39QTez1pw7bdEWCS91OkuHhtR6+Qd8SssUXdRwGBvStAUQVSGFQ/c d1Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=k/OObnDALy+CRuEhvRdZGyPx5qRQKx1YdTyfgXni3Ezb46kPyTzWFvPgRlXjd+1AiL Dz4J6/3H6/WTDUV0NZBB1+ESgvZOf9gP8FPI1f2qAMuDQNVNcgX0ZuS3Z+52mnwNnOQW fTu93trW50TdWrwXqagGbvB/E1BuIk4XjakFw8hW0MiAmPUJ9Lq41jOolgnVt82K82Km xKi+CYT1BJDt+3e4FIK6tlXPqda1qTFWhoEReQ1VO4WM7YqMGzgpYzsdav57eJBbpR8+ Rxtj9cKkcefJv7B3djpAwn07UddEml5q4Nx9BZqqCvjcocehM3c/bCCieorExisFxViB qePg== X-Gm-Message-State: AOJu0YxFuw39EdgJAeV2cHyfNQgP5HIQ2LgsyyIg74oV1XlHuD4CfizL ccdll60aeAL1srNuiMQdWy5Muni7Mlo= X-Google-Smtp-Source: AGHT+IE7TdAMSox3QZ9i3XY42vmW+YqwJtHLDXCrkzOQDSyIHqr/K/m4w9DaaKuedrPKXRX2zXN/sfp+lRA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:1cf:b0:1b9:df8f:888c with SMTP id e15-20020a17090301cf00b001b9df8f888cmr102903plh.8.1695393039713; Fri, 22 Sep 2023 07:30:39 -0700 (PDT) Date: Fri, 22 Sep 2023 07:30:38 -0700 In-Reply-To: <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-8-seanjc@google.com> <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Message-ID: Subject: Re: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Xiaoyao Li 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 Hildenbrand , Yu Zhang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chao Peng , linux-riscv@lists.infradead.org, Isaku Yamahata , Paul Moore , Marc Zyngier , Huacai Chen , James Morris , "Matthew Wilcox \(Oracle\)" , Wang , Fuad Tabba , Jarkko Sakkinen , "Serge E. Hallyn" , Maciej Szmigiero , Albert Ou , Vlastimil Babka , Michael Roth , Ackerley Tng , Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Quentin Perret , Liam Merwick , linux-mips@vger.kernel.org, Oliver Upton , linux-security-module@vger.kernel.org, Palmer Dabbelt , "Kirill A . Shutemov" , kvm-riscv@lists.infradead.org, Anup Patel , linux-fsdevel@vger.kernel.org, Paolo Bonzini , Andrew Morton , Vishal Annapurve , linuxppc-dev@lists.ozlabs.org, Xu Yilun , Anish Moorthy Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Sep 22, 2023, Xiaoyao Li wrote: > On 9/14/2023 9:55 AM, 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, > > side topic. > > Do we expect to integrate TDVMCALL(MAPGPA) of TDX into KVM_HC_MAP_GPA_RANGE? Yes, that's my expectation. > > 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. > > > > Place "struct memory_fault" in a second anonymous union so that filling > > memory_fault doesn't clobber state from other yet-to-be-fulfilled exits, > > and to provide additional information if KVM does NOT ultimately exit to > > userspace with KVM_EXIT_MEMORY_FAULT, e.g. if KVM suppresses (or worse, > > loses) the exit, as KVM often suppresses exits for memory failures that > > occur when accessing paravirt data structures. The initial usage for > > private memory will be all-or-nothing, but other features such as the > > proposed "userfault on missing mappings" support will use > > KVM_EXIT_MEMORY_FAULT for potentially _all_ guest memory accesses, i.e. > > will run afoul of KVM's various quirks. > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > the first union is valid? > > When exit reason is not KVM_EXIT_MEMORY_FAULT, how can we know the info in > the second union run.memory is valid without a run.memory.valid field? I'll respond to this separately with a trimmed Cc list. I suspect this will be a rather lengthy conversation, and it has almost nothing to do with guest_memfd. > > +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. > > + > > Initially, this section is the copy of struct kvm_run and had comments for > each field accordingly. Unfortunately, the consistence has not been well > maintained during the new filed being added. > > Do we expect to fix it? AFAIK, no one is working on cleaning up this section of the docs, but as always, patches are welcome :-) 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 80DB3E6FE3B for ; Fri, 22 Sep 2023 14:31:20 +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=9bob9h8XKshR4njraKYM/s3C8x/17t601DOL6kqjmKw=; b=njV0CP+o6Ukoib3w0x4Ez3Y1eA +yyeVVl9rbvLb4JqAv1Ffp3yjIl5HoinReyhj8Jpd8KfWL5kstfkyXdMulWVc3puxusyvO3Fuosfh nmJxmr2g14sm4C5MdRfvOtnd8ifzOfQGeI8tdqg9AFYFg5TQyJmYst1diZc5pILrCqXK896UhAGuZ pJS1srEZ+/Rp8ZtBDi1kc+O4RmaNya9lSJtPkg3doZ0qAc4aHgNJxtWcPGAX8ujruR3kAK00nPfIp +nSfEMPGrtLUcA9GLUS4qf8bT+HCR+cSKRUZU3gjUqavFczi4kMzPbNnEW/dyu1IbhEFnPPRMVmgv 7rgIGZ1A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qjhB9-009Ckz-1J; Fri, 22 Sep 2023 14:30:47 +0000 Received: from mail-pl1-x64a.google.com ([2607:f8b0:4864:20::64a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qjhB5-009Cii-2i for linux-arm-kernel@lists.infradead.org; Fri, 22 Sep 2023 14:30:45 +0000 Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1c5cfd475fbso16984615ad.1 for ; Fri, 22 Sep 2023 07:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=oGFdt5ZoSOtfQY/E9eQAlqh6boMh9E/NI0mstDro2N/fEjR2lpRyORybF/OE8vC/0u xybya70aLjhWPyOv3LsOQbHcJ+sq5oIC55IqvSzUv4tkgBdS2oWTE/rpGchmukGn+1Fb G5urGs+JquZJs4VfROrtgt0Bb/STfesPwwD5TygD5C2gz180lHm1kneIzUElFtQ7qETY wFKkqul9rGpi91IAgn9+9OrisB2xzA+oc7Kgc7Q14a7WO+9RfX0x5iyq/PbHqUBReKNe HcR1m0fDVkGm/3b092qm2WVVF1JYjfC4RrACJKJhSfgjvt1VtO1Y2DLI7FzWUeUYMl6R tw6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695393040; x=1695997840; 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=KA5pwz3/DRQHr6a2ee4M3bjnbEYA57TwsoBM67hI6zU=; b=W7dOgYHhM26iJp1YGCIl68UqfzIlYyTvwqcCigjgDZBM3UhOdCSlh5dta5XOLYeZdx PdaYZC0Rt+0dgRPoJEmB/5GFo/wxqTH5CO0zrIGw4rjXTM/Am3N94POnL6GNGNXPECDS z5q9M11QUOBvHihcdpdaRmYE24D2Pten3/HFjR+rySqhZcPMIN6Fm2ta7LLc0Bckyrl1 uXL1/1BehYGvZUYTbTm7bxRa+pJZ2ZgH5gYXDEZA97K93ZQ2REj26/ecAg7ncde7dH+o aLh33tgOh7YUuv6sQ4UrBSWfhQKAYEzQfWVBwNtpdKxjKqE0vj76MjlY0J+C/jbJxHpH vTBw== X-Gm-Message-State: AOJu0YxLsVqdJE1hsjaE39jTnWlN0Hp+gKcQDju6+jouNTl7Yl3qEUAo l0BtsO7evBQKdxDfYjCq3tPUGeIti4o= X-Google-Smtp-Source: AGHT+IE7TdAMSox3QZ9i3XY42vmW+YqwJtHLDXCrkzOQDSyIHqr/K/m4w9DaaKuedrPKXRX2zXN/sfp+lRA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:903:1cf:b0:1b9:df8f:888c with SMTP id e15-20020a17090301cf00b001b9df8f888cmr102903plh.8.1695393039713; Fri, 22 Sep 2023 07:30:39 -0700 (PDT) Date: Fri, 22 Sep 2023 07:30:38 -0700 In-Reply-To: <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-8-seanjc@google.com> <117db856-9aec-e91c-b1d4-db2b90ae563d@intel.com> Message-ID: Subject: Re: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace From: Sean Christopherson To: Xiaoyao Li Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , 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-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230922_073043_879344_BB7B8FFC X-CRM114-Status: GOOD ( 29.12 ) 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 Fri, Sep 22, 2023, Xiaoyao Li wrote: > On 9/14/2023 9:55 AM, 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, > > side topic. > > Do we expect to integrate TDVMCALL(MAPGPA) of TDX into KVM_HC_MAP_GPA_RANGE? Yes, that's my expectation. > > 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. > > > > Place "struct memory_fault" in a second anonymous union so that filling > > memory_fault doesn't clobber state from other yet-to-be-fulfilled exits, > > and to provide additional information if KVM does NOT ultimately exit to > > userspace with KVM_EXIT_MEMORY_FAULT, e.g. if KVM suppresses (or worse, > > loses) the exit, as KVM often suppresses exits for memory failures that > > occur when accessing paravirt data structures. The initial usage for > > private memory will be all-or-nothing, but other features such as the > > proposed "userfault on missing mappings" support will use > > KVM_EXIT_MEMORY_FAULT for potentially _all_ guest memory accesses, i.e. > > will run afoul of KVM's various quirks. > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > the first union is valid? > > When exit reason is not KVM_EXIT_MEMORY_FAULT, how can we know the info in > the second union run.memory is valid without a run.memory.valid field? I'll respond to this separately with a trimmed Cc list. I suspect this will be a rather lengthy conversation, and it has almost nothing to do with guest_memfd. > > +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. > > + > > Initially, this section is the copy of struct kvm_run and had comments for > each field accordingly. Unfortunately, the consistence has not been well > maintained during the new filed being added. > > Do we expect to fix it? AFAIK, no one is working on cleaning up this section of the docs, but as always, patches are welcome :-) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel