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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A28F2EB64D9 for ; Thu, 15 Jun 2023 14:40:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345081AbjFOOkg (ORCPT ); Thu, 15 Jun 2023 10:40:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57038 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345075AbjFOOkQ (ORCPT ); Thu, 15 Jun 2023 10:40:16 -0400 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4CFC1A2 for ; Thu, 15 Jun 2023 07:40:14 -0700 (PDT) Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-53f06f7cc74so526828a12.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=l+BcCOX6t84xt+Psqa1LGnyCZE7xLR0gXWNIldQIxcQeiAzXS9QMqGfSHkN3kd1Ckp QTdTOwDkripREcBx6/iKipwtw5Czv3gEY8/OJDDKfaGl7kpxCJXNjEXnokul2ia8p9ta LlkklluFj9UbmBwY7MTtF8cceg/l3EBNXJoH8InjrdD9iMITvJoWI1+YRyhpO91PiTzx +wVMqAyl0ivWp/Re6x2Wlr6/P0a8p/Jp9LJGzm6hnIY8EDMzBluHQ/e9j7k8VKahhjpI Kv3+X5oGXzR7IjLPggPy4drfBsERWH7bHX/FWYFI0Mj5v/MIjlRKimDtG6pinRvPT1M2 0OLw== X-Gm-Message-State: AC+VfDyIYixDuwarkyqDZSJ4WfZXlAOu+Sp8ItQb7qdCquzggkaheio/ MkmqyFPvRdg7wvrFsHd32fsSx266yWg= 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: 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" Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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.