From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (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 1022220E2 for ; Thu, 15 Jun 2023 14:40:14 +0000 (UTC) Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-53f06f7cc74so526829a12.1 for ; Thu, 15 Jun 2023 07:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1686840014; x=1689432014; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=bIrBNkZ9zKS9U5KeK7d+FaQMKemGy6nHExMMevpFFFU=; b=Rp2/4KfTpi/ecFRTS49d42Q664LFIcaODsBJ8mojuIxoCiwP/gG1eyjRC6hOxE60O/ 1aKKYOpSESIfe8WmOSkMMiBM+iSWB3a15qlxX34wypFNvlC4axW87m7MzWZKakvED9dn lvtxAKI8GGht6q9NqiGo1yJn87y01XPJl1Gg0fjsb4XjMLhRbVuBrdWPdT9XxBlSf53Z MY30Bz8TW+rmFWJaoFxtt/SWyoL+R20m+vlM59nOEbrLIbhpzo7Fx31h40qeNiE4sLcl T6UtDjvMfqP6cWk52PaxYEKiGSJWKbMPWboALiSToUzDmaHx2KC21YkoXyXEYQGjeDg5 RAoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686840014; x=1689432014; 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=bIrBNkZ9zKS9U5KeK7d+FaQMKemGy6nHExMMevpFFFU=; b=cF/C6oslMqnYMb5A4uf/nX4U1AfhFtcspqvNesnVE+iOjtEXXip0qamSk1mIDm+aKv aPgGX5hJE2lQe4wYluX087LvKrSZ5oxsVdvjxax+a8oRdLeazG4xvo0OaOg+g6Z8Ils3 T653N3wtjaGZKWGu3WxzfsyfHnHSzzHD/yZB4DE6t9tx/b1CMFbYFZu7pcwg03dCLU7n 65ynGzOWqElBv51lGVHo1juNyzNJOWLEbmWL80wl6mqrSadW6zJ8RmNuJa7Tvov1nlVz z0ryc9Zs+BAW7BkUQCSHSSKtwi21Pl4VbNKCam3mviOt97soyegaVyqT33ZAP72Mmdj+ Zxkg== X-Gm-Message-State: AC+VfDz5ZJ8t96I9n8p9EqdgN30+DG4Z0LPqkmX3Dl+F+AbTA1mb3Oej LlwlLTLiNn1fARtMOjJQx+/DQl+e8E4= X-Google-Smtp-Source: ACHHUZ4ImrZRGKXrUehYcg6Mu58huGQo2fCvfr3+VnpcSsl+lnS/4G/v4KJtNEzrOEcBexGy313QNxHZVA4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a63:f30c:0:b0:53f:9e36:1d58 with SMTP id l12-20020a63f30c000000b0053f9e361d58mr739967pgh.0.1686840014295; Thu, 15 Jun 2023 07:40:14 -0700 (PDT) Date: Thu, 15 Jun 2023 07:40:12 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230602161921.208564-1-amoorthy@google.com> <20230602161921.208564-9-amoorthy@google.com> Message-ID: Subject: Re: [PATCH v4 08/16] KVM: x86: Annotate -EFAULTs from kvm_handle_error_pfn() From: Sean Christopherson To: Robert Hoo Cc: Anish Moorthy , oliver.upton@linux.dev, kvm@vger.kernel.org, kvmarm@lists.linux.dev, pbonzini@redhat.com, maz@kernel.org, jthoughton@google.com, bgardon@google.com, dmatlack@google.com, ricarkol@google.com, axelrasmussen@google.com, peterx@redhat.com, nadav.amit@gmail.com, isaku.yamahata@gmail.com Content-Type: text/plain; charset="us-ascii" On Thu, Jun 15, 2023, Robert Hoo wrote: > On 6/3/2023 12:19 AM, Anish Moorthy wrote: > > Implement KVM_CAP_MEMORY_FAULT_INFO for efaults generated by > > kvm_handle_error_pfn(). > > > > Signed-off-by: Anish Moorthy > > --- > > arch/x86/kvm/mmu/mmu.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > > index c8961f45e3b1..cb71aae9aaec 100644 > > --- a/arch/x86/kvm/mmu/mmu.c > > +++ b/arch/x86/kvm/mmu/mmu.c > > @@ -3291,6 +3291,10 @@ static void kvm_send_hwpoison_signal(struct kvm_memory_slot *slot, gfn_t gfn) > > static int kvm_handle_error_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault) > > { > > + uint64_t rounded_gfn; > > + uint64_t fault_size; > > + uint64_t fault_flags; > > + > > if (is_sigpending_pfn(fault->pfn)) { > > kvm_handle_signal_exit(vcpu); > > return -EINTR; > > @@ -3309,6 +3313,15 @@ static int kvm_handle_error_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fa > > return RET_PF_RETRY; > > } > > + fault_size = KVM_HPAGE_SIZE(fault->goal_level); > > IIUC, here fault->goal_level is always PG_LEVEL_4K. > goal_level could be adjusted in later kvm_tdp_mmu_map() --> > kvm_mmu_hugepage_adjust(), if kvm_faultin_pfn() doesn't fail, that is to > say, code path doesn't go through here. > > I wonder, if you would like put (kind of) kvm_mmu_hugepage_adjust() here as > well, reporting to user space the maximum map size it could do with, OR, > just report 4K size, let user space itself to detect/decide max possible > size (but now I've no idea how to). No, that's nonsensical because KVM uses the host mapping to compute the max mapping level. If there's no valid mapping, then there's no defined level. And as I said in my reply, KVM should never kick out to userspace if KVM can establish a 4KiB mapping, i.e. 4KiB is always the effective scope, and reporting anything else would just be wild speculation.