From: Naman Jain <[email protected]> Sent: Friday, October 17, 2025 12:45 AM > > Introduce a new mshv_vtl driver to provide an interface for Virtual > Machine Monitor like OpenVMM and its use as OpenHCL paravisor to > control VTL0 (Virtual trust Level). > Expose devices and support IOCTLs for features like VTL creation, > VTL0 memory management, context switch, making hypercalls, > mapping VTL0 address space to VTL2 userspace, getting new VMBus > messages and channel events in VTL2 etc. > > OpenVMM : https://openvmm.dev/guide/ > > Changes since v8: > https://lore.kernel.org/all/[email protected]/ > Addressed Sean's comments: > * Removed forcing SIGPENDING, and other minor changes, in > mshv_vtl_ioctl_return_to_lower_vtl after referring > to Sean's earlier changes for xfer_to_guest_mode_handle_work. > > * Rebased and resolved merge conflicts, compilation errors on latest > linux-next kernel tip, after Roman's Confidential VM changes, > which merged recently. No functional changes.
Did your testing against the latest linux-next included testing with CONFIG_X86_KERNEL_IBT=y? This is Indirect Branch Tracking, which would have generated a fault with your v7 series and earlier because of the indirect call instruction when doing VTL Return through the hypercall page (which doesn't have the needed ENDBR64 instruction). But now that VTL Return is doing a static call, that should be direct, which won't trigger an IBT fault. To confirm that you really are running with IBT enabled, you should see [ 0.047008] CET detected: Indirect Branch Tracking enabled in the VTL2 dmesg output. And "ibt" should appear in the "flags" output line of 'cat /proc/cpuinfo' (or the 'lscpu' command). Michael
