Re: [PATCH] x86/nSVM: Validate the L1 MSRPM physical address range

[Lin Liu <lin.liu01@xxxxxxxxxx>]

On 16.09.2026 07:07, Jan Beulich wrote:
> Non-RAM is rejected in other situations as well, where in principle the
> same behavior you describe could apply. Hence imo if we wanted to go
> that route, I think we'd want to be consistent. That would be quite a
> bit more work.

Agreed - I'm dropping the series.

My premise was wrong in any case.  15.10.1 (p.537) and 15.11 (p.539) both
say the map "should reside in memory that is mapped as writeback (WB)",
which I had missed, so an unbacked map is outside the contract rather
than legal-but-refused.  The range check is redundant too: an
out-of-range address cannot be populated, so the copy already rejects it.

And "match what hardware does" would not be a consistent rule even in
principle, because hardware is not uniform here.  On EPYC 9255 / 9965 /
8324P, with a non-nested guest's own VMCB pointed at each address:

  in-range unpopulated hole       accepted; map reads as all ones
  SMRAM (inside an enabled TSeg)  VMRUN hard-rejected, both maps
  one page above TSeg             accepted

The TSeg boundary is the discriminator, not MMIO-vs-RAM; Andrew predicted
that offline.  One incidental result: at that last address the bitmap is
real firmware data, the EFER read bit happened to be clear, and the guest
read the host's real EFER with SVME set before triple-faulting - an
argument for rejecting rather than guessing.

Thanks for the help to review.

Lin