Re: [PATCH v2 07/15] arm64: hyperv: Add support for mshv_vtl_return_call

[Marc Zyngier <maz@kernel.org>]

On Wed, 29 Apr 2026 10:56:11 +0100,
Naman Jain <namjain@linux.microsoft.com> wrote:
> 

[...]

> Merging threads for addressing comments from Mark Rutland and Marc
> Zyngier on this patch.
> 
> Thanks for reviewing the changes. Please allow me to briefly explain
> the use case here and then address your comments.
> 
> Hyper-V's Virtual Trust Levels (VTLs) provide hardware-enforced
> isolation within a single VM, analogous to ARM TrustZone. The kernel
> runs in VTL2 (higher privilege) as a "paravisor", a security monitor
> that handles intercepts for the primary OS in VTL0 (lower
> privilege). The VTL switch (mshv_vtl_return_call) is functionally
> equivalent to KVM's guest enter/exit. It saves VTL2 state, loads
> VTL0's GPRs other registers from a shared context structure, issues
> hvc #3 to let VTL0 run, and on return saves VTL0's updated state back.

No, this is fundamentally different. KVM is purely architectural,
doesn't try to "sanitise" anything, and context switches *all* of the
guest state. No ifs, no buts, no "reserved registers".

[...]

> Regarding Non-SMCCC "hvc #3" call, I have a limitation here owing to
> the ABI that is defined by the Hyper-V hypervisor. Fixing this
> requires a hypervisor-side change to support SMCCC-style dispatch for
> VTL return. Until then, hvc #3 is the only working interface. Moreover
> there would be backward compatibility issues with this new ABI
> interface, if at all it is added.

Left hand, please talk to right hand. This is not the first time we
push back on this, and we already had this annoying discussion back
when arm64 as a Hyper-V guest was first proposed (6, 7 years ago?).

What has changed since? Absolutely nothing.

If the Hyper-V folks decide to ignore the standard and go their own
way, that's fine. They only get to keep the pieces.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.