Re: [RFC PATCH 07/12] drivers: hv: hv_vsm_boot: load secure kernel image from firmware

[Thara Gopinath <tgopinath@linux.microsoft.com>]

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 <skinsburskii@linux.microsoft.com>
>> Signed-off-by: Thara Gopinath <tgopinath@linux.microsoft.com>
>> ---
>>  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