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 780C036AB61 for ; Wed, 4 Mar 2026 16:42:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772642561; cv=none; b=ezB1QFTLPALx5EMEGJigM54miBwzlBCxP+s4OBcl4QmTPbvM9aliwKVuCLpY0I1WdwMfd0WgmhnpePOzJFpUvzQeub5gNuvXxxUH2m5ddqE9ZIlVJ/urksACoD+ERYv9zRhWbh5IJIZeav+pjANuTPkz6mJm0cJ1VCubX4nnz80= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772642561; c=relaxed/simple; bh=EXdvy/X2qckXmE4Fn4pxUupwjsevzcJ8qc5ZO33j78o=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=VrPDE+TrAK4xgace3pU7k9P6Cw3G/0DA3EEg5txMvyRl1h5kuPG9MBqD0xTs/eM96iqT5nphPihuZmEQTRHpJR6WqW42WUc0qWZugBFcYAXuZj5CKYSzxWw31EBT+YXyhR/egyKvVTZmDWVCuYb6iSM4Mkxs0MdTzzuCyZA6lj8= 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=ewe1IPmo; arc=none smtp.client-ip=209.85.214.201 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="ewe1IPmo" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-2ae61939fa5so49002465ad.0 for ; Wed, 04 Mar 2026 08:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772642558; x=1773247358; 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=LKOTPS+x5qyyOBePt2E7Wo7x4Cp+H26djNH9mCsw8A8=; b=ewe1IPmo8NfNn85vq3td323umUZgOzwxSyXxc4Q/SQhssL2JZLmy5JjnRDW1pkTZwM nAX6uUGqkLDaqUt/M2mwLu8wN7ueKRZUHvI8cKe4Zr4tUWK3bu330U7x0S3dgGC9wsIE E0CVNo5NZzeUXVmw6q8guWpM/2iicWNs8uwGHy2BvT5AHAaaoc+krL9wWwf2oJI2uGB4 xcUsCSJp+F1J1cynoBnGpwAyu7NogIYf/Ak2vutV0KFpR2RnRikKcFzzS3Ft0LM+EmHu lcSgM1Fv8+aMOullztu8yVWrhn+4TWG+/AtcuBnevaQ8RieiQ9/dTz+JTNwXen4HJ+Bg EIAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772642558; x=1773247358; 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=LKOTPS+x5qyyOBePt2E7Wo7x4Cp+H26djNH9mCsw8A8=; b=WqjT36VcYLND7bzMglvNJoJPsiTBP4e2+7Qpf9ngQcLZuc63QjFlTyqVCGyf+dw2Y4 b5Yf7/z2Cfz8TyLJ/TreOE/O0HS81JBUT1X/rnWvivvviNvjb+CJJBDZw/3wk7/UgeyZ 29B34puQhHwp/+wewgPIB9/zda4Hfgy9u4wdRX3G+9+x+SGPdYrj/BxaETghdML1C6JV NoQIRFgty/ZV/UaPTgFyOxruAOdnqNmlFz9sLKAS+7sSy/vCQG128NrbESlKYC1T7+DB 1T/zLH6GxABrp2+tptVhY1SGsscIgyxgNYqvFRo7MolbmCSL15ccCX7CRtc9Vvg+85aK 9Hrg== X-Forwarded-Encrypted: i=1; AJvYcCXr0fEJDv3Kw0tnBQR0vtQSZIwGf4CfcAmtXaYU6h4I7qs5BTp3go56eNlYSC6kIKxxMHb/iSgRLmA9hD4=@vger.kernel.org X-Gm-Message-State: AOJu0Yx5OWe5/m78t9/ri8Sh0QpQDqcmzLROKj2ti+r9z+yA7qXOhUUc qiPHCWN8TD+rPSw8t+fLVamNOhTQXjG+X9UvW8Rj4Wz9efDP9An+tfWRUbpEN3YbmGAL6hKQQ+p Q7ZSszw== X-Received: from pggq20.prod.google.com ([2002:a63:d614:0:b0:c73:8741:7555]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:d703:b0:38e:90ca:5a2b with SMTP id adf61e73a8af0-3982deb4e22mr2628840637.17.1772642557478; Wed, 04 Mar 2026 08:42:37 -0800 (PST) Date: Wed, 4 Mar 2026 08:42:36 -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: <20251026201911.505204-1-xin@zytor.com> <20251026201911.505204-13-xin@zytor.com> <60C180BF-AD13-48EF-9BA8-CEACF57965EF@zytor.com> <1EA97017-82D2-4C43-B617-D39C68D7BC6F@zytor.com> Message-ID: Subject: Re: [PATCH v9 12/22] KVM: VMX: Virtualize FRED event_data From: Sean Christopherson To: Xin Li Cc: "H. Peter Anvin" , Chao Gao , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, luto@kernel.org, peterz@infradead.org, andrew.cooper3@citrix.com, hch@infradead.org, sohil.mehta@intel.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 29, 2026, Xin Li wrote: > > On Jan 29, 2026, at 9:21=E2=80=AFAM, H. Peter Anvin wro= te: > >=20 > >> Just to confirm, you are referring to requeueing an original event > >> via vmx_complete_interrupts(), right? > >>=20 > >> Regardless of whether FRED or IDT is in use, the event payload is deli= vered > >> into the appropriate guest state and then invalidated in > >> kvm_deliver_exception_payload(): > >>=20 > >> 1) CR2 for #PF > >>=20 > >> 2) DR6 for #DB > >>=20 > >> 3) guest_fpu.xfd_err for #NM (in handle_nm_fault_irqoff()) > >>=20 > >> We should be able to recover the FRED event data from there. > >>=20 > >> Alternatively, we could drop the original event and allow the hardware= to > >> regenerate it upon resuming the guest. However, this breaks #DB deliv= ery, > >> as debug exceptions sometimes are triggered post-instruction. > >>=20 > >> Sean, does it make sense to recover the FRED event data from guest CPU= state? No? As Peter points out, the payload is tied to the exception and shouldn'= t change. > > I think some bits in DR6 are "sticky", and so unless the guest has > > explicitly cleared DR6 the event data isn't necessarily derivable from = DR6. > > However, the FRED event data for #DB is directly based on the data alre= ady > > reported by VTx (for exactly the same reason =E2=80=93 knowing what the= *currently > > taken* trap represents.) >=20 > Yeah, it's important to keep in mind that DR6 bits are 'sticky'. >=20 > Regarding vmx_complete_interrupts(), when a VM migration occurs immediate= ly > following a VM exit with a valid original event saved in the VMCS, we can > safely assume the guest DR6 state remains consistent with the original ev= ent > data because there is no chance for guest OS to modify DR6. There's a different problem though. If there's a re-injected exception at = the time of save/restore, the destination vCPU won't see a valid payload and th= us won't set the appropriate FRED VMCS fields. We _could_ extend KVM's uAPI to save/restore event_data, but ugh. Rather t= han add event_data, what if we reuse payload, and then simply skip updating reg= ister state on re-injection? E.g. diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 967b58a8ab9d..b79d545d69c7 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1941,6 +1941,9 @@ void vmx_inject_exception(struct kvm_vcpu *vcpu) u32 intr_info =3D ex->vector | INTR_INFO_VALID_MASK; struct vcpu_vmx *vmx =3D to_vmx(vcpu); =20 + if (ex->has_payload) + ; + kvm_deliver_exception_payload(vcpu, ex); =20 if (ex->has_error_code) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index db3f393192d9..485eec337203 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -773,6 +773,9 @@ void kvm_deliver_exception_payload(struct kvm_vcpu *vcp= u, if (!ex->has_payload) return; =20 + if (ex->injected) + goto clear_payload; + switch (ex->vector) { case DB_VECTOR: /* @@ -814,6 +817,7 @@ void kvm_deliver_exception_payload(struct kvm_vcpu *vcp= u, break; } =20 +clear_payload: ex->has_payload =3D false; ex->payload =3D 0; }