[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f3959d60-9622-4817-8b85-2b704c46c583@citrix.com>
Date: Wed, 11 Feb 2026 00:53:56 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: shivansh.dhiman@....com
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, bp@...en8.de,
dave.hansen@...ux.intel.com, hpa@...or.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, mingo@...hat.com, nikunj.dadhania@....com,
pbonzini@...hat.com, santosh.shukla@....com, seanjc@...gle.com,
tglx@...utronix.de, x86@...nel.org, xin@...or.com
Subject: Re: [PATCH 0/7] KVM: SVM: Enable FRED support
> Here is the newly published FRED virtualization spec by AMD for reference:
>
> https://docs.amd.com/v/u/en-US/69191-PUB
>
> Please feel free to share any feedback or questions.
FYI, there is a fun behaviour captured in the sentence:
"If FRED virtualization is enabled, NMI virtualization must be enabled
in order to properly handle guest NMIs"
i.e. hypervisors need to make sure not run the guest with FRED &&
!vNMI. AIUI, there's no ERETUx intercept similar to the IRET intercept
with with to emulate NMI window tracking in !vNMI mode.
I requested that this become a VMRUN consistency check, but was
declined. I've asked that at least the wording change to "undefined
behaviour" so something sane can be done for the nested case where L1
tries to do something daft.
There are two other issues which are going to be adjusted. One is the
consistency check concerning SS.DPL==3 && INTR_SHADOW==0 (not a valid
restriction in later drafts of the spec), and one is "On an intercepted
#DB, EXITINFO2 has DR6 register value." Both do/will (not sure which)
behave like Intel, rather than as currently documented.
~Andrew
Powered by blists - more mailing lists