mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: shivansh.dhiman@amd.com
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	mingo@redhat.com, nikunj.dadhania@amd.com, pbonzini@redhat.com,
	santosh.shukla@amd.com, seanjc@google.com, tglx@linutronix.de,
	x86@kernel.org, xin@zytor.com
Subject: Re: [PATCH 0/7] KVM: SVM: Enable FRED support
Date: Wed, 11 Feb 2026 00:53:56 +0000	[thread overview]
Message-ID: <f3959d60-9622-4817-8b85-2b704c46c583@citrix.com> (raw)
In-Reply-To: <85958aa8-98ee-40bc-8fcf-750bbf62ccce@amd.com>

> 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

  reply	other threads:[~2026-02-11  0:54 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-29  6:36 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
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-08-10  8:39     ` Shivansh Dhiman
2026-08-12 23:27       ` Sean Christopherson
2026-08-13  8:19         ` Nikunj A. Dadhania
2026-08-13 23:47           ` Sean Christopherson
2026-08-14  3:07             ` Nikunj A. Dadhania
2026-08-14 16:57               ` Sean Christopherson
2026-08-19 12:08         ` Shivansh Dhiman
2026-08-21 13:28           ` Sean Christopherson
2026-08-24  6:30             ` Shivansh Dhiman
2026-02-06  9:22 ` [PATCH 0/7] KVM: SVM: Enable FRED support Shivansh Dhiman
2026-02-11  0:53   ` Andrew Cooper [this message]
2026-03-06  9:33     ` Shivansh Dhiman
2026-03-03 17:58 ` Shivansh Dhiman

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=f3959d60-9622-4817-8b85-2b704c46c583@citrix.com \
    --to=andrew.cooper3@citrix.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=seanjc@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®