Re: [PATCH] x86/svm: require VMSAVEvirt for nested virt

[Stephen Cheng <stephen.cheng@xxxxxxxxxx>]

On 27/07/2026 11:48, Teddy Astie wrote:
> I'm not convinced making "VMSAVEvirt" mandatory is a good idea, in
> particular, there is a errata (1454 - Processor May Log Unexpected LS
> MCE Error When Executing Virtualized VMLOAD or Virtualized VMSAVE) on
> Family 19h regarding this feature.

Thank you, I hadn't looked at 1454.  Quoting it here for anyone else
following along:

  Description
  Under a highly specific and detailed set of internal timing
  conditions, when a virtualized VMLOAD or virtualized VMSAVE
  instruction is executed the processor may log an uncorrectable LS
  MCE error of the type "HWA" with:
   MCA::LS::MCA_STATUS_LS[ErrorCodeExt] = 0x16 and
   MCA::LS::MCA_SYND_LS[ErrorInformation] = 0x00094.

  Potential Effect on System
  System may log a fatal error and reset.

  Suggested Workaround
  System software may contain the workaround for this erratum.

  Fix Planned
  No fix planned

I don't think this patch changes the exposure, though.  A part affected
by 1454 has the feature by definition, and on such a part staging
already enables it for every nested guest -- see the existing
cpu_has_svm_vloadsave path in svm_nested_features_on_efer_update().
What this patch removes is the emulation fallback used on hosts which
lack the feature, and those hosts cannot hit 1454 in the first place.
The set of machines exposed to the erratum is therefore the same before
and after.

That doesn't make 1454 a non-issue -- "may log a fatal error and reset"
with "no fix planned" is worth understanding.  But it's an existing
question about Xen's use of virtual VMLOAD/VMSAVE rather than something
this patch introduces, and answering it means deliberately not enabling
a feature Xen enables today.  I'd rather do that knowingly, once we
know what the workaround is: "system software may contain the
workaround" doesn't say whether that means firmware, microcode or the
hypervisor.

> Had you considered improving the current implementation of virtualized
> VMLOAD/VMSAVE ? AIUI, the way Xen currently implements this instruction
> (by mapping the L1 VMCB then calling vmload/vmsave on it) is more of a
> implementation choice than a requirement.
>
> A better (at least, likely safer) way to emulate such instructions (and
> not relying on VMSAVEvirt) would be to copy parts of L1 VMCB from/to L0
> VMCB and let Xen perform the appropriate vmload/vmsave on its own VMCBs
> as usual.

You're right that it's an implementation choice rather than a hardware
requirement.  On whether it's worth building, I'll defer to Ross's
reply: given how limited our resources for nested virt are, and that
AMD nested virt doesn't work today, dropping support for older parts
isn't a functional regression.

Thanks for the review and the feedback.

Stephen