From: Sean Christopherson <seanjc@google.com>
To: Amit Shah <Amit.Shah@amd.com>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"pawan.kumar.gupta@linux.intel.com"
<pawan.kumar.gupta@linux.intel.com>,
"kai.huang@intel.com" <kai.huang@intel.com>,
"jpoimboe@kernel.org" <jpoimboe@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"daniel.sneddon@linux.intel.com"
<daniel.sneddon@linux.intel.com>,
Thomas Lendacky <Thomas.Lendacky@amd.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
Babu Moger <Babu.Moger@amd.com>,
Sandipan Das1 <Sandipan.Das@amd.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"bp@alien8.de" <bp@alien8.de>,
"boris.ostrovsky@oracle.com" <boris.ostrovsky@oracle.com>,
David Kaplan <David.Kaplan@amd.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v6 1/1] x86: kvm: svm: set up ERAPS support for guests
Date: Tue, 25 Nov 2025 06:54:22 -0800 [thread overview]
Message-ID: <aSXDHq4vUdB8Zqsv@google.com> (raw)
In-Reply-To: <718b02d4cfa56a65cb2383a0e57ca988defc036b.camel@amd.com>
On Tue, Nov 25, 2025, Amit Shah wrote:
> On Mon, 2025-11-24 at 16:40 +0000, Andrew Cooper wrote:
> > > > So punting on emulating RAP clearing because it's too hard is not
> > > > an option. And AFAICT, it's not even that hard.
> > > I didn't mean on punting it in the "it's too hard" sense, but in the
> > > sense that we don't know all the details of when hardware decides to do a
> > > flush; and even if triggers are mentioned in this APM today, future
> > > changes to microcode or APM docs might reveal more triggers that we need
> > > to emulate and account for. There's no way to track such changes, so my
> > > thinking is that we should be conservative and not assume anything.
> >
> > But this *is* the problem. The APM says that OSes can depend on this
> > property for safety, and does not provide enough information for
> > Hypervisors to make it safe.
>
> That's certainly true - that's driving my reluctance to perform the
> emulation or in enabling it for cases that aren't completely clear.
Uh, I think you're misunderstanding what Andrew and I are saying. Doing nothing
is the worst option.
> > ERAPS is a bad spec. It should not have gotten out of the door.
> >
> > A better spec would say "clears the RAP on any MOV to CR3" and
> > nothing else.
> >
> > The fact that it might happen microarchitecturally in other cases doesn't
> > matter; what matters is what OSes can architecturally depend on, and right
> > now that that explicitly includes "unspecified cases in NDA documents".
>
> To be honest, I haven't seen the mention of those unspecified cases or
> NDA documents.
>
> However, at least for the case of an NPT guest, the hypervisor does not
> need to do anything special (other than handle nested guests as this
> patch does).
How on earth do you come to that conclusion? I'm genuinely baffled as to why
you think it's safe to completely ignore RAP clears that are architecturally
supposed to happen from the guest's perspective.
next prev parent reply other threads:[~2025-11-25 14:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 9:32 [PATCH v6 0/1] KVM: Add support for the ERAPS feature Amit Shah
2025-11-07 9:32 ` [PATCH v6 1/1] x86: kvm: svm: set up ERAPS support for guests Amit Shah
2025-11-20 20:11 ` Sean Christopherson
2025-11-21 2:40 ` Andrew Cooper
2025-11-21 14:58 ` Sean Christopherson
2025-11-21 15:21 ` Andrew Cooper
2025-11-24 16:15 ` Shah, Amit
2025-11-24 16:40 ` Andrew Cooper
2025-11-25 14:41 ` Shah, Amit
2025-11-25 14:54 ` Sean Christopherson [this message]
2025-12-11 16:09 ` Shah, Amit
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=aSXDHq4vUdB8Zqsv@google.com \
--to=seanjc@google.com \
--cc=Amit.Shah@amd.com \
--cc=Babu.Moger@amd.com \
--cc=David.Kaplan@amd.com \
--cc=Sandipan.Das@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).