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 ?
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
