On Wed, Sep 02, 2026 at 12:22:37PM -0400, Thara Gopinath wrote:
>
>
> On 9/2/2026 12:37 AM, Wei Liu wrote:
> > 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.
>
> Ah no.. So securekernel= has to be specified in the command line for
> __setup() to be invoked . It can be left blank without parameters like
> securekernel= or with parameters like securekernel=256M@0x80000000. The
> reservation logic will take care of reserving the correct memory if there
> are no parameters but if there is no command line specified __setup will
> not be called. The other way of solving this and invoking the reservations
> unconditionally will be to call it from setup_arch like how
> reserve_crashkernel
> is invoked. I am not sure if we want to do that now ?? What do you think ?
>
I see. No need to do that now. Let's see if others have opinions.
Wei
> But I will reword this and state that the panic happens if there is no
> securekernel memory allocated (either because securekernel= was not
> specified or because memory reservation itself failed)
>
> >
> >>
> >> 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.
>
> I will fix this
>
> Warm Regards
> Thara
> >
> > Wei
>
