On 5/8/2026 2:55 PM, Marc Zyngier wrote:
On Wed, 29 Apr 2026 10:56:11 +0100,
Naman Jain <[email protected]> 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".
[...]
Acked.
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.
Thanks for the feedback. I understand your and Mark’s concerns with this
approach now, and I’ve initiated internal discussions with the team to
explore potential solutions.
Regards,
Naman
