On Tue, Sep 01, 2026 at 09:55:21AM -0700, Thara Gopinath wrote:
> LVBS bring-up requires loading a secure kernel image into VTL1 before
> starting it. Add the VTL0-side loader that stages the image in the
> memory region reserved by hv_vsm_securekernel, in preparation for the
> VTL1 bring-up.
>
> The image is a 64-bit ELF fetched via request_firmware("vsm_sk"). It
> is expected to ship inside the signed UKI/initramfs so it is
> authenticated end-to-end via Secure Boot before the loader consumes
> it; sourcing it from an unauthenticated location would break the LVBS
> trust model.
>
> The loader validates the ELF header, stages the PT_LOAD segments into
> the reserved region and records the entry point as a physical address
> for use at VTL1 start time.
>
> If VSM support has been advertised to the hypervisor but no secure
> kernel region was reserved on the command line, panic: LVBS bring-up
> is committed at this point and there is no safe way to continue.
This conflicts with the memory reservation patch, in which there is an
automatic allocation when no kernel command line is specified.
>
> Signed-off-by: Stanislav Kinsburskii <[email protected]>
> Signed-off-by: Thara Gopinath <[email protected]>
> ---
> drivers/hv/hv_vsm.h | 17 ++++
> drivers/hv/hv_vsm_boot.c | 201 ++++++++++++++++++++++++++++++++++++++-
> include/hyperv/vsm.h | 21 ++++
> 3 files changed, 238 insertions(+), 1 deletion(-)
> create mode 100644 drivers/hv/hv_vsm.h
> create mode 100644 include/hyperv/vsm.h
[...]
> +
> +static void __init hv_vsm_get_sk_mem(void)
> +{
> + /*
> + * The reserved secure kernel region is mandatory once VSM support has
> + * been advertised. Without it we cannot load the secure kernel and
> + * bringing up VTL1 is impossible, so fail hard rather than continuing
> + * in an unusable state.
> + */
> + if (!sk_res.start)
> + panic("No memory reserved in cmdline for secure kernel");
> +
This log line is wrong.
Wei
