Re: [PATCH v6 1/1] x86: kvm: svm: set up ERAPS support for guests

["Shah, Amit" <Amit.Shah@amd.com>]

On Mon, 2025-11-24 at 16:40 +0000, Andrew Cooper wrote:


[...]

> 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.
> 
> 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".

I'd like to clarify and confirm the details around TLB flushes and
their effects of ERAPS here as an official AMD statement. First, I'd
like to clarify that INVLPGB does not flush the RAP.

Second,

Referring to the APM at

https://docs.amd.com/v/u/en-US/24593_3.43

Section 3.2.9: move to CR3 and the execution of INVPCID are the
instructions that result in the flushing of the ERAPS.

The reference to section 5.3.3 - TLB Management - and the implicit TLB
flushes there was unclear which led to most of the speculation in this
discussion earlier in this thread.  For the section 5.3.3, we will
update the APM to clarify that the "writes to certain MSRs" relates to
microarchitectural behavior.

The updated wording for section 5.3.3 will make its way in a future APM
update.

(For the curious, the list of those MSRs currently is APIC_BASE,
PREFETCH_CONTROL, SYSCFG, IORRs, TOM/TOM2, SMMADDR/MASK, ECS_BASE, but
of course this is subject to change.)

Coming back to the patch here with these clarifications from AMD
architects - I am happy with Sean's update to the patch.  I've also
tested the patch and it works as expected on a Zen5 CPU.

Reviewed-by: Amit Shah <amit.shah@amd.com>

Thanks,

		Amit