From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.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 67D1433A010 for ; Tue, 24 Feb 2026 20:28:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771964885; cv=none; b=jHZAQQ2JSiuFKmhWX+uwMx5upQ7jFtMGrgyO8aehWm16fCc+Bzc2GB5siQ+8Q+PMSr0YT6YgVZsrVDrcPm12IX0Y8JuIzbvbwsnKkd3jO6OuufdyYNEHzsSHx9diF5IXihHp52B0x5F+lqbdFmMl1NKgfdXPTc8JvV/9Wg9x0Ws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771964885; c=relaxed/simple; bh=H8Z/wHLxfxbn474umNh3WAH4BiduAReGh1P42RVVsV8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=C1zYYKkXT6PAVnQa+RHvejURL0TrlRI8jSCG4ZrrAas1HCBYSePKDAOxka6mFlCzSGXtSNqI7lTwQTsKLQgfaTBcTiXensqNq9gpBGZ4D7zZqzwChg8n4tYTWwL0pJWM4WggcroIlXM1+M60zRSX7BTt62aOVkN5x/y7VPWoW4I= 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=vCgjv5Ty; arc=none smtp.client-ip=209.85.214.202 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="vCgjv5Ty" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2aad5fec175so245300905ad.2 for ; Tue, 24 Feb 2026 12:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771964883; x=1772569683; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=GskECAkP1j4sD1Dc3We/Ha9bUAOBCBlhdIAksTGltow=; b=vCgjv5Ty9jvvCmQdbEdjxMDUxji6rjtV/JMBX2CX3PHXMzjIts0UXArbauAVp1B2sv x1Mq+R7HDdQ44R1ZLIqegftlMt4OdnQ2iuCyNQMlBoXVWLwgP9CGs02e1qEYjJY9RJ6E LA1AKadvZhXEy8LwKkIhgYsAZEy4tjYYwEqlouy8Y5KTIM+xNNSXsGUOxb92CVQsKtpZ OKqccgE+5z2PBJJaN/SlCcxTaYVLgjT/wAcqvsLCIJ5WHD2vahGczMQ60KdEXbeDSTz+ 3NRiEwsq1ErXWl3zEAxm/0HEgGtIQA77m7MWUR4WMd2/Uz6OqNoQuCjRM/sBJ4bz+uc1 w+cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771964883; x=1772569683; h=content-transfer-encoding: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=GskECAkP1j4sD1Dc3We/Ha9bUAOBCBlhdIAksTGltow=; b=Pv8Az5I81dE4nf0Tte1YhflUEyrbZ1yBYSrBnbDnnuGpFSRND5RqDwhdzya79pAYlZ 3JwVAG3aw/nHRfN4dirloVvEN10kXZcVBop/166G+10MBuRbeRkfZP/IgnyhRclT8Vjn 3cRndSx23nFqCNNuHtGdVVC3ZqSosq0kLVe5sWF1Hd0V2AkErMcWoT/Lq3yIAovCo1qw opsQCFk2SyA9gFo6Zt4u/KSSlZlDIDLalktdGvM30vMq2A8a1VCzCgz0g0+SNmz51ukb 3jfPDWCc+oNuvgdGwkU822BbnC9HD/kMyhdSwiBes+MQRlHLCLqOD0heFHwHUV9Iorto kJwA== X-Forwarded-Encrypted: i=1; AJvYcCUGfJOdfIm1GG+6DMTsy7MSq9kN5CMjz2sNvxjJoTPd/JFnuAjTHXja6+tils+ItpT1+A/0lKTz9TVzXLo=@vger.kernel.org X-Gm-Message-State: AOJu0Yw3olnEt5NgV8RlDNkbTBW8l7MdRDwueL18IN5ODCWQJ//XwwXP d0QhDkNzL8R7f9u5RpREYnzbFxxJPNRJypKzFoUf0oi/0UeHR7BZg09lBq/hpELXymFGCh+x5/h mnQ49Vg== X-Received: from pgvt10.prod.google.com ([2002:a65:64ca:0:b0:c6d:b680:d2ec]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:4782:b0:38e:9e55:6dee with SMTP id adf61e73a8af0-39545f7b042mr11615641637.57.1771964882568; Tue, 24 Feb 2026 12:28:02 -0800 (PST) Date: Tue, 24 Feb 2026 12:28:01 -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="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2026, Yosry Ahmed wrote: > On Tue, Feb 24, 2026 at 11:37=E2=80=AFAM Sean Christopherson wrote: > > > > On Tue, Feb 24, 2026, Yosry Ahmed wrote: > > > > > @@ -496,7 +510,7 @@ static int FNAME(walk_addr_generic)(struct gu= est_walker *walker, > > > > > * [2:0] - Derive from the access bits. The exit_qualificat= ion might be > > > > > * out of date if it is serving an EPT misconfigura= tion. > > > > > * [5:3] - Calculated by the page walk of the guest EPT pag= e 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(stru= ct kvm_vcpu *vcpu, > > > > > exit_qualification =3D 0; > > > > > } else { > > > > > exit_qualification =3D fault->exit_qualific= ation; > > > > > - exit_qualification |=3D vmx_get_exit_qual(v= cpu) & > > > > > - (EPT_VIOLATION_GVA_IS= _VALID | > > > > > - EPT_VIOLATION_GVA_TR= ANSLATED); > > > > > > > > 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_ foll= ow hardware. > > > > > > > > Aha! I think the easiest way to deal with that is to flag nested p= age faults > > > > that were the result of walking L1's TDP when handling an L2 TDP pa= ge 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 L= 2 > > > 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 tabl= es". > > > > I.e. when servicing an L2 TDP fault, KVM is only resolving the fault fo= r the reported > > L2 GPA, _not_ the originating L2 GVA (if there is one). >=20 > I see. Does this need special handling when forwarding #NPFs to L1 as > well? Or will fault->error_code have the HW fault bits in > nested_svm_inject_npf_exit() in this case? Yes, sorry for not making that it explicit. nested_svm_inject_npf_exit() w= ould also need to consult hardware_nested_page_fault.