From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 C85EA30F52C for ; Tue, 24 Feb 2026 19:37:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771961863; cv=none; b=CB7TSNYMcM4xNq/kbuUIyEocNqsxY5MqUa4kh2c9Q2+UTqFcQXmdgnY9plTnOhu/a8yNi+6ZbiwVx/BHs5PLk3mkakNmB6InMWdJ9HTa4tF7p58yTfkfqrDDAkZbktE6CN98C7lNUZC+00J59XdaH397GOll+oVI4gHv0Z3tjbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771961863; c=relaxed/simple; bh=TUjME4e4ee/WT/NlNRYr/K81TzZEWNbu4EqawuIqT9c=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=IZmoqWfD8C23OJYO4tqELj3TO3d8AkJWYsF077ssLrTcZvmkzliDuCUtLZqLD8ZllzD5o52G1PDV2kkct3qDY9n6tp5UFwj41qya4vryK0AWKnvu4pa86eAcKCKY23lV0k+ae+xRamn3olfoLixI+9Y3r7zJx3ordcB3HAPR5Tk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ose65Rib; arc=none smtp.client-ip=209.85.216.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ose65Rib" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-354c0eb08ceso37622874a91.1 for ; Tue, 24 Feb 2026 11:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771961860; x=1772566660; darn=vger.kernel.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=y4OyuNHT7ap5XzoM1m50GD/I12ZIB1MFriXuxmmpl50=; b=Ose65Rib3jgeAF/H6S6ISu/jsPEYQMOPV7/UqGqud6ZEy/YTh+pGhILe5F518wZOKw OPscuy1pLFjZc/D+aItJrH9fFG2vf2xww1dMHl1R/qLuIPevTPI9cTFERKLvrh7LwAc5 Hh+whtNp9swnF5ozbZ459dowfG0jMqperScX1nbS6MjVCtdyDU03YZZqIz1L0ZhtA709 bFZS6KMPclHJrRQhfVjf3AUBtsiONe3E0NzcML2xaXRumpq/1epc7gjsjN2fUVNSk3xV U9NgB5KzQFzAAzpPgEl1S6ZOqu3dkz5vPMe84Y2D+V+wK5BgQdU0HWJBgPoH0YQTdqsC Xb+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771961860; x=1772566660; 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=y4OyuNHT7ap5XzoM1m50GD/I12ZIB1MFriXuxmmpl50=; b=K1U2uW1JkNA4xG98nkjqdKyh8eK8YSoX7gkXqislMVLGmkOIYR6Gslx0k2gFUyuZSt Uxm5R1s2oSKsAk2tDiRWojbi164nly6jQwbi5PLLgVBscduvyUHH0Va5Q3HncojRTcc6 5X29AeqZRomMbE3krUZW9tdsI5IwUAPtxmxKnxyXOyhOiG8rJZJxprGNScLu0aMAwj7K miomZUrhJE4WvIS2qMCk65M7akUuR07x+zmlKg9laHryNez5Nm2DaAIRkUcu1P14IHtK AvxDa2vi7/6uIMOFuVRmAIQpuIGqbbKEbmB0QGVyTUzoSrQUCCtQ3xTnVUOg7GdrWj+R 2g0A== X-Forwarded-Encrypted: i=1; AJvYcCW/GzUEgpEgTLTvlztjqodd24KAWx3VlDAXCgH1T4Z3H/XmCA/Il38AWJlLmomxUaYLEnU5VMpvv3JBoBI=@vger.kernel.org X-Gm-Message-State: AOJu0YxHwS0Ut6NMMw4gEXYfN3FVDXn9ZsAyoaVYgdTH5L41bCTRyBSg CbvhhcLVyrGD6WFyfT8IDstWXNfqjKBH0gBK2Wazygv/mnoefWioKcazGnK9moZ9wvoTc0PtZbY Bb8aCNA== X-Received: from pjqf14.prod.google.com ([2002:a17:90a:a78e:b0:354:9f74:37d]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:35c8:b0:353:5595:3246 with SMTP id 98e67ed59e1d1-358ae8b6672mr10708334a91.21.1771961859876; Tue, 24 Feb 2026 11:37:39 -0800 (PST) Date: Tue, 24 Feb 2026 11:37:38 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260224071822.369326-1-chengkev@google.com> <20260224071822.369326-4-chengkev@google.com> Message-ID: Subject: Re: [PATCH V2 3/4] KVM: VMX: Don't consult original exit qualification for nested EPT violation injection From: Sean Christopherson To: Yosry Ahmed Cc: Kevin Cheng , pbonzini@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, yosry.ahmed@linux.dev Content-Type: text/plain; charset="us-ascii" On Tue, Feb 24, 2026, Yosry Ahmed wrote: > > > @@ -496,7 +510,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker, > > > * [2:0] - Derive from the access bits. The exit_qualification might be > > > * out of date if it is serving an EPT misconfiguration. > > > * [5:3] - Calculated by the page walk of the guest EPT page tables > > > - * [7:8] - Derived from [7:8] of real exit_qualification > > > + * [7:8] - Set at the kvm_translate_gpa() call sites above > > > * > > > * The other bits are set to 0. > > > */ > > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > > > index 248635da67661..6a167b1d51595 100644 > > > --- a/arch/x86/kvm/vmx/nested.c > > > +++ b/arch/x86/kvm/vmx/nested.c > > > @@ -444,9 +444,6 @@ static void nested_ept_inject_page_fault(struct kvm_vcpu *vcpu, > > > exit_qualification = 0; > > > } else { > > > exit_qualification = fault->exit_qualification; > > > - exit_qualification |= vmx_get_exit_qual(vcpu) & > > > - (EPT_VIOLATION_GVA_IS_VALID | > > > - EPT_VIOLATION_GVA_TRANSLATED); > > > > Hmm, this isn't quite correct. If KVM injects an EPT Violation (or a #NPF) when > > handling an EPT Violation (or #NPF) from L2, then KVM _should_ follow hardware. > > > > Aha! I think the easiest way to deal with that is to flag nested page faults > > that were the result of walking L1's TDP when handling an L2 TDP page fault, and > > then let vendor code extract the fault information out of hardaware. > > Is it not possible that KVM gets an EPT Violation (or a #NPF) on an L2 > memory access while the CPU is walking L2's page tables, then KVM > walks L1's TDP and finds mappings for the L2 page tables but not the > final translation? Or will KVM always just fixup the immediate EPT > Violation (or #NPF) by inserting a shadow mapping of L2's page tables > and retry the instruction immediately? The latter, assuming by "shadow mapping of L2's page tables" out meant "installing a shadow mapping of the faulting L2 GPA according to L1's TDP page tables". I.e. when servicing an L2 TDP fault, KVM is only resolving the fault for the reported L2 GPA, _not_ the originating L2 GVA (if there is one).