From: Sean Christopherson <seanjc@google.com>
To: Shivansh Dhiman <shivansh.dhiman@amd.com>
Cc: pbonzini@redhat.com, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, xin@zytor.com, nikunj.dadhania@amd.com,
santosh.shukla@amd.com
Subject: Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields
Date: Mon, 9 Mar 2026 11:57:35 -0700 [thread overview]
Message-ID: <aa8YH4yzXAXGiL4k@google.com> (raw)
In-Reply-To: <7c5d0db9-5151-4edb-9b97-0f0b268cf36e@amd.com>
On Mon, Mar 09, 2026, Shivansh Dhiman wrote:
> Hey Sean,
>
> On 07-03-2026 07:28, Sean Christopherson wrote:
> > On Thu, Jan 29, 2026, Shivansh Dhiman wrote:
> >> From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
> >>
> >> The upcoming AMD FRED (Flexible Return and Event Delivery) feature
> >> introduces several new fields to the VMCB save area. These fields include
> >> FRED-specific stack pointers (fred_rsp[0-3], fred_ssp[1-3]), stack level
> >> tracking (fred_stklvls), and configuration (fred_config).
> >>
> >> Ensure that a vCPU starts with a clean and valid FRED state on
> >> capable hardware. Also update the size of save areas of VMCB.
> >
> >> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> >> index f4ccb3e66635..5cec971a1f5a 100644
> >> --- a/arch/x86/kvm/svm/svm.c
> >> +++ b/arch/x86/kvm/svm/svm.c
> >> @@ -1110,6 +1110,16 @@ static void init_vmcb(struct kvm_vcpu *vcpu, bool init_event)
> >> save->idtr.base = 0;
> >> save->idtr.limit = 0xffff;
> >>
> >> + save->fred_rsp0 = 0;
> >> + save->fred_rsp1 = 0;
> >> + save->fred_rsp2 = 0;
> >> + save->fred_rsp3 = 0;
> >> + save->fred_stklvls = 0;
> >> + save->fred_ssp1 = 0;
> >> + save->fred_ssp2 = 0;
> >> + save->fred_ssp3 = 0;
> >> + save->fred_config = 0;
> >
> > Is this architecturally correct? I.e. are all the FRED MSRs zeroed on INIT?
>
> Yes that's right, the FRED MSRs are zeroed on init.
Please use that as the basis for the changelog. "Ensure that a vCPU starts with
a clean and valid FRED state on capable hardware" is largely meaningless because
vCPU structures are zero-allocated.
next prev parent reply other threads:[~2026-03-09 18:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-29 6:36 [PATCH 0/7] KVM: SVM: Enable FRED support Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields Shivansh Dhiman
2026-03-07 1:58 ` Sean Christopherson
2026-03-09 17:46 ` Shivansh Dhiman
2026-03-09 18:57 ` Sean Christopherson [this message]
2026-03-11 4:18 ` Shivansh Dhiman
2026-03-27 6:41 ` Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 2/7] KVM: SVM: Disable interception of FRED MSRs for FRED supported guests Shivansh Dhiman
2026-03-07 2:10 ` Sean Christopherson
2026-03-09 17:47 ` Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 3/7] KVM: SVM: Save restore FRED_RSP0 " Shivansh Dhiman
2026-03-05 20:37 ` Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 4/7] KVM: SVM: Populate FRED event data on event injection Shivansh Dhiman
2026-03-06 11:31 ` Paolo Bonzini
2026-03-09 19:47 ` Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 5/7] KVM: SVM: Support FRED nested exception injection Shivansh Dhiman
2026-03-07 2:07 ` Sean Christopherson
2026-03-10 15:56 ` Shivansh Dhiman
2026-03-10 16:20 ` Sean Christopherson
2026-03-11 4:12 ` Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 6/7] KVM: SVM: Dump FRED context in dump_vmcb() Shivansh Dhiman
2026-03-07 2:03 ` Sean Christopherson
2026-03-09 19:57 ` Shivansh Dhiman
2026-01-29 6:36 ` [PATCH 7/7] KVM: SVM: Enable save/restore of FRED MSRs Shivansh Dhiman
2026-03-07 2:14 ` Sean Christopherson
2026-03-09 18:20 ` Shivansh Dhiman
2026-02-06 9:22 ` [PATCH 0/7] KVM: SVM: Enable FRED support Shivansh Dhiman
2026-02-11 0:53 ` Andrew Cooper
2026-03-06 9:33 ` Shivansh Dhiman
2026-03-03 17:58 ` Shivansh Dhiman
-- strict thread matches above, loose matches on Subject: below --
2026-03-14 12:55 Re: [PATCH 1/7] KVM: SVM: Initialize FRED VMCB fields Christian Ludloff
2026-03-27 6:47 ` Shivansh Dhiman
2026-03-27 7:29 ` Christian Ludloff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa8YH4yzXAXGiL4k@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj.dadhania@amd.com \
--cc=pbonzini@redhat.com \
--cc=santosh.shukla@amd.com \
--cc=shivansh.dhiman@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.