Hi all,

This RFC patch series introduces relocatable uncompressed kernel image,
which is allowed to perform kerenl image virtual address randomization
in 64-bit booting entry instead of decompression phase.

- Background

Currently, kernel image virtual address randomization is only performed
during the decompression phase. However, in certain scenarios, such as
secure container environments (e.g., Kata Containers), to speed up the
boot process, the system may boot directly from an uncompressed kernel
image. In such cases, virtual address randomization cannot be executed.
Although the security enhancement provided by KASLR is limited, there is
still a potential demand to allow uncompressed kernel images to perform
virtual address randomization (for example, future support for x86 PIE).

- Approaches

Currently, the x86 kernel uses static compilation, but it retains
relocation information through the '--emit-relocs' option, which is then
simplified into a relocation table using 'relocs' tool. To enable
virtual address randomization for uncompressed kernel images, relocation
information is required, and there are several possible approaches:

1) Who will perform the randomization:

VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform
randomization. This would require additional modifications to the VMM,
and vmlinux.relocs needs to be packaged when shipping.

Kernel: The kernel performs randomization itself at the kernel
entry point, requiring no modifications to the VMM.

2) relocation information format:

vmlinux.relocs: It only contains the necessary relocation entries and is
simplified, making it small enough. However, it is a format defined
within the kernel that was previously used only internally and is not
part of the ABI.

rela.* sections: It is the standard ELF ABI, but
it contains RIP-relative relocation entries, which are more common in
kernel, causing the kernel image to be larger.

- Implementation

The final implementation of this plan extends the 'relocs' tool to allow
the insertion of relocation information into a reserved section of the
kernel (referencing the MIPS implementation). This enables the reading
of that information and subsequent execution of relocations when booting
directly from an uncompressed kernel. Currently, this implementation is
only available for 64-bit and has been tested with both PVH entry
booting and standard 64-bit Linux entry. And the default reserve size is
1MB for now, which is enough for defconfig.

- TODO

Clean up the decompression KASLR code to allow it to be shared with the
booting phase.


Thanks!

Hou Wenlong (5):
  x86/relocs: Cleanup cmdline options
  x86/relocs: Insert relocations into input file
  x86: Allow to build relocatable uncompressed kernel binary
  x86/boot: Perform virtual address relocation in kernel entry
  x86/boot: Use '.data.relocs' section for performing relocations during
    decompression

 arch/x86/Kconfig                  |  20 ++++++
 arch/x86/Makefile.postlink        |  33 +++++++++
 arch/x86/boot/compressed/Makefile |   6 +-
 arch/x86/boot/compressed/misc.c   |   8 +++
 arch/x86/boot/startup/Makefile    |   1 +
 arch/x86/boot/startup/kaslr.c     | 116 ++++++++++++++++++++++++++++++
 arch/x86/include/asm/setup.h      |   1 +
 arch/x86/kernel/head_64.S         |   7 ++
 arch/x86/kernel/vmlinux.lds.S     |  20 ++++++
 arch/x86/lib/cmdline.c            |   6 ++
 arch/x86/lib/kaslr.c              |   5 ++
 arch/x86/platform/pvh/head.S      |  15 +++-
 arch/x86/tools/relocs.c           |  64 ++++++++++++++---
 arch/x86/tools/relocs.h           |  15 ++--
 arch/x86/tools/relocs_common.c    |  24 ++++---
 15 files changed, 309 insertions(+), 32 deletions(-)
 create mode 100644 arch/x86/Makefile.postlink
 create mode 100644 arch/x86/boot/startup/kaslr.c

--
2.31.1

On January 26, 2026 5:33:50 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
>Hi all,
>
>This RFC patch series introduces relocatable uncompressed kernel image,
>which is allowed to perform kerenl image virtual address randomization
>in 64-bit booting entry instead of decompression phase.
>
>- Background
>
>Currently, kernel image virtual address randomization is only performed
>during the decompression phase. However, in certain scenarios, such as
>secure container environments (e.g., Kata Containers), to speed up the
>boot process, the system may boot directly from an uncompressed kernel
>image. In such cases, virtual address randomization cannot be executed.
>Although the security enhancement provided by KASLR is limited, there is
>still a potential demand to allow uncompressed kernel images to perform
>virtual address randomization (for example, future support for x86 PIE).
>
>- Approaches
>
>Currently, the x86 kernel uses static compilation, but it retains
>relocation information through the '--emit-relocs' option, which is then
>simplified into a relocation table using 'relocs' tool. To enable
>virtual address randomization for uncompressed kernel images, relocation
>information is required, and there are several possible approaches:
>
>1) Who will perform the randomization:
>
>VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform
>randomization. This would require additional modifications to the VMM,
>and vmlinux.relocs needs to be packaged when shipping.
>
>Kernel: The kernel performs randomization itself at the kernel
>entry point, requiring no modifications to the VMM.
>
>2) relocation information format:
>
>vmlinux.relocs: It only contains the necessary relocation entries and is
>simplified, making it small enough. However, it is a format defined
>within the kernel that was previously used only internally and is not
>part of the ABI.
>
>rela.* sections: It is the standard ELF ABI, but
>it contains RIP-relative relocation entries, which are more common in
>kernel, causing the kernel image to be larger.
>
>- Implementation
>
>The final implementation of this plan extends the 'relocs' tool to allow
>the insertion of relocation information into a reserved section of the
>kernel (referencing the MIPS implementation). This enables the reading
>of that information and subsequent execution of relocations when booting
>directly from an uncompressed kernel. Currently, this implementation is
>only available for 64-bit and has been tested with both PVH entry
>booting and standard 64-bit Linux entry. And the default reserve size is
>1MB for now, which is enough for defconfig.
>
>- TODO
>
>Clean up the decompression KASLR code to allow it to be shared with the
>booting phase.
>
>
>Thanks!
>
>Hou Wenlong (5):
>  x86/relocs: Cleanup cmdline options
>  x86/relocs: Insert relocations into input file
>  x86: Allow to build relocatable uncompressed kernel binary
>  x86/boot: Perform virtual address relocation in kernel entry
>  x86/boot: Use '.data.relocs' section for performing relocations during
>    decompression
>
> arch/x86/Kconfig                  |  20 ++++++
> arch/x86/Makefile.postlink        |  33 +++++++++
> arch/x86/boot/compressed/Makefile |   6 +-
> arch/x86/boot/compressed/misc.c   |   8 +++
> arch/x86/boot/startup/Makefile    |   1 +
> arch/x86/boot/startup/kaslr.c     | 116 ++++++++++++++++++++++++++++++
> arch/x86/include/asm/setup.h      |   1 +
> arch/x86/kernel/head_64.S         |   7 ++
> arch/x86/kernel/vmlinux.lds.S     |  20 ++++++
> arch/x86/lib/cmdline.c            |   6 ++
> arch/x86/lib/kaslr.c              |   5 ++
> arch/x86/platform/pvh/head.S      |  15 +++-
> arch/x86/tools/relocs.c           |  64 ++++++++++++++---
> arch/x86/tools/relocs.h           |  15 ++--
> arch/x86/tools/relocs_common.c    |  24 ++++---
> 15 files changed, 309 insertions(+), 32 deletions(-)
> create mode 100644 arch/x86/Makefile.postlink
> create mode 100644 arch/x86/boot/startup/kaslr.c
>
>--
>2.31.1
>

Hi!

At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. 

Thanks! 

On Mon, Jan 26, 2026 at 11:30:28AM -0800, H. Peter Anvin wrote:
> On January 26, 2026 5:33:50 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
> >Hi all,
> >
> >This RFC patch series introduces relocatable uncompressed kernel image,
> >which is allowed to perform kerenl image virtual address randomization
> >in 64-bit booting entry instead of decompression phase.
> >
> >- Background
> >
> >Currently, kernel image virtual address randomization is only performed
> >during the decompression phase. However, in certain scenarios, such as
> >secure container environments (e.g., Kata Containers), to speed up the
> >boot process, the system may boot directly from an uncompressed kernel
> >image. In such cases, virtual address randomization cannot be executed.
> >Although the security enhancement provided by KASLR is limited, there is
> >still a potential demand to allow uncompressed kernel images to perform
> >virtual address randomization (for example, future support for x86 PIE).
> >
> >- Approaches
> >
> >Currently, the x86 kernel uses static compilation, but it retains
> >relocation information through the '--emit-relocs' option, which is then
> >simplified into a relocation table using 'relocs' tool. To enable
> >virtual address randomization for uncompressed kernel images, relocation
> >information is required, and there are several possible approaches:
> >
> >1) Who will perform the randomization:
> >
> >VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform
> >randomization. This would require additional modifications to the VMM,
> >and vmlinux.relocs needs to be packaged when shipping.
> >
> >Kernel: The kernel performs randomization itself at the kernel
> >entry point, requiring no modifications to the VMM.
> >
> >2) relocation information format:
> >
> >vmlinux.relocs: It only contains the necessary relocation entries and is
> >simplified, making it small enough. However, it is a format defined
> >within the kernel that was previously used only internally and is not
> >part of the ABI.
> >
> >rela.* sections: It is the standard ELF ABI, but
> >it contains RIP-relative relocation entries, which are more common in
> >kernel, causing the kernel image to be larger.
> >
> >- Implementation
> >
> >The final implementation of this plan extends the 'relocs' tool to allow
> >the insertion of relocation information into a reserved section of the
> >kernel (referencing the MIPS implementation). This enables the reading
> >of that information and subsequent execution of relocations when booting
> >directly from an uncompressed kernel. Currently, this implementation is
> >only available for 64-bit and has been tested with both PVH entry
> >booting and standard 64-bit Linux entry. And the default reserve size is
> >1MB for now, which is enough for defconfig.
> >
> >- TODO
> >
> >Clean up the decompression KASLR code to allow it to be shared with the
> >booting phase.
> >
> >
> >Thanks!
> >
> >Hou Wenlong (5):
> >  x86/relocs: Cleanup cmdline options
> >  x86/relocs: Insert relocations into input file
> >  x86: Allow to build relocatable uncompressed kernel binary
> >  x86/boot: Perform virtual address relocation in kernel entry
> >  x86/boot: Use '.data.relocs' section for performing relocations during
> >    decompression
> >
> > arch/x86/Kconfig                  |  20 ++++++
> > arch/x86/Makefile.postlink        |  33 +++++++++
> > arch/x86/boot/compressed/Makefile |   6 +-
> > arch/x86/boot/compressed/misc.c   |   8 +++
> > arch/x86/boot/startup/Makefile    |   1 +
> > arch/x86/boot/startup/kaslr.c     | 116 ++++++++++++++++++++++++++++++
> > arch/x86/include/asm/setup.h      |   1 +
> > arch/x86/kernel/head_64.S         |   7 ++
> > arch/x86/kernel/vmlinux.lds.S     |  20 ++++++
> > arch/x86/lib/cmdline.c            |   6 ++
> > arch/x86/lib/kaslr.c              |   5 ++
> > arch/x86/platform/pvh/head.S      |  15 +++-
> > arch/x86/tools/relocs.c           |  64 ++++++++++++++---
> > arch/x86/tools/relocs.h           |  15 ++--
> > arch/x86/tools/relocs_common.c    |  24 ++++---
> > 15 files changed, 309 insertions(+), 32 deletions(-)
> > create mode 100644 arch/x86/Makefile.postlink
> > create mode 100644 arch/x86/boot/startup/kaslr.c
> >
> >--
> >2.31.1
> >
> 
> Hi!
> 
> At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. 
>
 
Hi!

Uh, sorry that it may not meet your needs. In fact, it will slow down
when booting directly from an uncompressed kernel. The improvement
described in the patchset compares booting directly from vmlinux versus
booting from bzImage when we want to enable KASLR for guests in MicroVM
scenarios. There is a similar idea in [0], where KASLR randomization is
implemented on the VMM side. Now we want to implement it directly in the
guest kernel to reduce modifications to the VMMs. There are some
measurements in [0]; however, the comparison is between vmlinux and
bzImage.

In my test environment, compared to the original direct kernel booting,
it would add 2ms for my test configuration [1] based on the Kata
Containers repository due to the self-relocation phase. Booting from
bzImage does not affect the boot time, as it simply inserts
'vmlinux.relocs' into vmlinux, resulting in no change to the total size.
The decompression time should also not be affected; I didn't notice any
difference when measuring the decompression().

[0]: https://dl.acm.org/doi/epdf/10.1145/3492321.3519578
[1]: https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config

Thanks!

> Thanks!

On January 27, 2026 4:03:07 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
>On Mon, Jan 26, 2026 at 11:30:28AM -0800, H. Peter Anvin wrote:
>> On January 26, 2026 5:33:50 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
>> >Hi all,
>> >
>> >This RFC patch series introduces relocatable uncompressed kernel image,
>> >which is allowed to perform kerenl image virtual address randomization
>> >in 64-bit booting entry instead of decompression phase.
>> >
>> >- Background
>> >
>> >Currently, kernel image virtual address randomization is only performed
>> >during the decompression phase. However, in certain scenarios, such as
>> >secure container environments (e.g., Kata Containers), to speed up the
>> >boot process, the system may boot directly from an uncompressed kernel
>> >image. In such cases, virtual address randomization cannot be executed.
>> >Although the security enhancement provided by KASLR is limited, there is
>> >still a potential demand to allow uncompressed kernel images to perform
>> >virtual address randomization (for example, future support for x86 PIE).
>> >
>> >- Approaches
>> >
>> >Currently, the x86 kernel uses static compilation, but it retains
>> >relocation information through the '--emit-relocs' option, which is then
>> >simplified into a relocation table using 'relocs' tool. To enable
>> >virtual address randomization for uncompressed kernel images, relocation
>> >information is required, and there are several possible approaches:
>> >
>> >1) Who will perform the randomization:
>> >
>> >VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform
>> >randomization. This would require additional modifications to the VMM,
>> >and vmlinux.relocs needs to be packaged when shipping.
>> >
>> >Kernel: The kernel performs randomization itself at the kernel
>> >entry point, requiring no modifications to the VMM.
>> >
>> >2) relocation information format:
>> >
>> >vmlinux.relocs: It only contains the necessary relocation entries and is
>> >simplified, making it small enough. However, it is a format defined
>> >within the kernel that was previously used only internally and is not
>> >part of the ABI.
>> >
>> >rela.* sections: It is the standard ELF ABI, but
>> >it contains RIP-relative relocation entries, which are more common in
>> >kernel, causing the kernel image to be larger.
>> >
>> >- Implementation
>> >
>> >The final implementation of this plan extends the 'relocs' tool to allow
>> >the insertion of relocation information into a reserved section of the
>> >kernel (referencing the MIPS implementation). This enables the reading
>> >of that information and subsequent execution of relocations when booting
>> >directly from an uncompressed kernel. Currently, this implementation is
>> >only available for 64-bit and has been tested with both PVH entry
>> >booting and standard 64-bit Linux entry. And the default reserve size is
>> >1MB for now, which is enough for defconfig.
>> >
>> >- TODO
>> >
>> >Clean up the decompression KASLR code to allow it to be shared with the
>> >booting phase.
>> >
>> >
>> >Thanks!
>> >
>> >Hou Wenlong (5):
>> >  x86/relocs: Cleanup cmdline options
>> >  x86/relocs: Insert relocations into input file
>> >  x86: Allow to build relocatable uncompressed kernel binary
>> >  x86/boot: Perform virtual address relocation in kernel entry
>> >  x86/boot: Use '.data.relocs' section for performing relocations during
>> >    decompression
>> >
>> > arch/x86/Kconfig                  |  20 ++++++
>> > arch/x86/Makefile.postlink        |  33 +++++++++
>> > arch/x86/boot/compressed/Makefile |   6 +-
>> > arch/x86/boot/compressed/misc.c   |   8 +++
>> > arch/x86/boot/startup/Makefile    |   1 +
>> > arch/x86/boot/startup/kaslr.c     | 116 ++++++++++++++++++++++++++++++
>> > arch/x86/include/asm/setup.h      |   1 +
>> > arch/x86/kernel/head_64.S         |   7 ++
>> > arch/x86/kernel/vmlinux.lds.S     |  20 ++++++
>> > arch/x86/lib/cmdline.c            |   6 ++
>> > arch/x86/lib/kaslr.c              |   5 ++
>> > arch/x86/platform/pvh/head.S      |  15 +++-
>> > arch/x86/tools/relocs.c           |  64 ++++++++++++++---
>> > arch/x86/tools/relocs.h           |  15 ++--
>> > arch/x86/tools/relocs_common.c    |  24 ++++---
>> > 15 files changed, 309 insertions(+), 32 deletions(-)
>> > create mode 100644 arch/x86/Makefile.postlink
>> > create mode 100644 arch/x86/boot/startup/kaslr.c
>> >
>> >--
>> >2.31.1
>> >
>> 
>> Hi!
>> 
>> At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. 
>>
> 
>Hi!
>
>Uh, sorry that it may not meet your needs. In fact, it will slow down
>when booting directly from an uncompressed kernel. The improvement
>described in the patchset compares booting directly from vmlinux versus
>booting from bzImage when we want to enable KASLR for guests in MicroVM
>scenarios. There is a similar idea in [0], where KASLR randomization is
>implemented on the VMM side. Now we want to implement it directly in the
>guest kernel to reduce modifications to the VMMs. There are some
>measurements in [0]; however, the comparison is between vmlinux and
>bzImage.
>
>In my test environment, compared to the original direct kernel booting,
>it would add 2ms for my test configuration [1] based on the Kata
>Containers repository due to the self-relocation phase. Booting from
>bzImage does not affect the boot time, as it simply inserts
>'vmlinux.relocs' into vmlinux, resulting in no change to the total size.
>The decompression time should also not be affected; I didn't notice any
>difference when measuring the decompression().
>
>[0]: https://dl.acm.org/doi/epdf/10.1145/3492321.3519578
>[1]: https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config
>
>Thanks!
>
>> Thanks! 

Didn't you say that that was the reason for this? I'm confused now.

On Tue, Jan 27, 2026 at 07:43:14AM -0800, H. Peter Anvin wrote:
> On January 27, 2026 4:03:07 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
> >On Mon, Jan 26, 2026 at 11:30:28AM -0800, H. Peter Anvin wrote:
> >> On January 26, 2026 5:33:50 AM PST, Hou Wenlong <houwenlong.hwl@antgroup.com> wrote:
> >> >Hi all,
> >> >
> >> >This RFC patch series introduces relocatable uncompressed kernel image,
> >> >which is allowed to perform kerenl image virtual address randomization
> >> >in 64-bit booting entry instead of decompression phase.
> >> >
> >> >- Background
> >> >
> >> >Currently, kernel image virtual address randomization is only performed
> >> >during the decompression phase. However, in certain scenarios, such as
> >> >secure container environments (e.g., Kata Containers), to speed up the
> >> >boot process, the system may boot directly from an uncompressed kernel
> >> >image. In such cases, virtual address randomization cannot be executed.
> >> >Although the security enhancement provided by KASLR is limited, there is
> >> >still a potential demand to allow uncompressed kernel images to perform
> >> >virtual address randomization (for example, future support for x86 PIE).
> >> >
> >> >- Approaches
> >> >
> >> >Currently, the x86 kernel uses static compilation, but it retains
> >> >relocation information through the '--emit-relocs' option, which is then
> >> >simplified into a relocation table using 'relocs' tool. To enable
> >> >virtual address randomization for uncompressed kernel images, relocation
> >> >information is required, and there are several possible approaches:
> >> >
> >> >1) Who will perform the randomization:
> >> >
> >> >VMM: The VMM reads vmlinux.relocs after loading vmlinux to perform
> >> >randomization. This would require additional modifications to the VMM,
> >> >and vmlinux.relocs needs to be packaged when shipping.
> >> >
> >> >Kernel: The kernel performs randomization itself at the kernel
> >> >entry point, requiring no modifications to the VMM.
> >> >
> >> >2) relocation information format:
> >> >
> >> >vmlinux.relocs: It only contains the necessary relocation entries and is
> >> >simplified, making it small enough. However, it is a format defined
> >> >within the kernel that was previously used only internally and is not
> >> >part of the ABI.
> >> >
> >> >rela.* sections: It is the standard ELF ABI, but
> >> >it contains RIP-relative relocation entries, which are more common in
> >> >kernel, causing the kernel image to be larger.
> >> >
> >> >- Implementation
> >> >
> >> >The final implementation of this plan extends the 'relocs' tool to allow
> >> >the insertion of relocation information into a reserved section of the
> >> >kernel (referencing the MIPS implementation). This enables the reading
> >> >of that information and subsequent execution of relocations when booting
> >> >directly from an uncompressed kernel. Currently, this implementation is
> >> >only available for 64-bit and has been tested with both PVH entry
> >> >booting and standard 64-bit Linux entry. And the default reserve size is
> >> >1MB for now, which is enough for defconfig.
> >> >
> >> >- TODO
> >> >
> >> >Clean up the decompression KASLR code to allow it to be shared with the
> >> >booting phase.
> >> >
> >> >
> >> >Thanks!
> >> >
> >> >Hou Wenlong (5):
> >> >  x86/relocs: Cleanup cmdline options
> >> >  x86/relocs: Insert relocations into input file
> >> >  x86: Allow to build relocatable uncompressed kernel binary
> >> >  x86/boot: Perform virtual address relocation in kernel entry
> >> >  x86/boot: Use '.data.relocs' section for performing relocations during
> >> >    decompression
> >> >
> >> > arch/x86/Kconfig                  |  20 ++++++
> >> > arch/x86/Makefile.postlink        |  33 +++++++++
> >> > arch/x86/boot/compressed/Makefile |   6 +-
> >> > arch/x86/boot/compressed/misc.c   |   8 +++
> >> > arch/x86/boot/startup/Makefile    |   1 +
> >> > arch/x86/boot/startup/kaslr.c     | 116 ++++++++++++++++++++++++++++++
> >> > arch/x86/include/asm/setup.h      |   1 +
> >> > arch/x86/kernel/head_64.S         |   7 ++
> >> > arch/x86/kernel/vmlinux.lds.S     |  20 ++++++
> >> > arch/x86/lib/cmdline.c            |   6 ++
> >> > arch/x86/lib/kaslr.c              |   5 ++
> >> > arch/x86/platform/pvh/head.S      |  15 +++-
> >> > arch/x86/tools/relocs.c           |  64 ++++++++++++++---
> >> > arch/x86/tools/relocs.h           |  15 ++--
> >> > arch/x86/tools/relocs_common.c    |  24 ++++---
> >> > 15 files changed, 309 insertions(+), 32 deletions(-)
> >> > create mode 100644 arch/x86/Makefile.postlink
> >> > create mode 100644 arch/x86/boot/startup/kaslr.c
> >> >
> >> >--
> >> >2.31.1
> >> >
> >> 
> >> Hi!
> >> 
> >> At a very quick glance this seems like a very reasonable thing to me, but since the intent is reduced boot latency (a very worthwhile goal!) do you perhaps have any measurements to show how much improvement we are talking about? That would be really useful. 
> >>
> > 
> >Hi!
> >
> >Uh, sorry that it may not meet your needs. In fact, it will slow down
> >when booting directly from an uncompressed kernel. The improvement
> >described in the patchset compares booting directly from vmlinux versus
> >booting from bzImage when we want to enable KASLR for guests in MicroVM
> >scenarios. There is a similar idea in [0], where KASLR randomization is
> >implemented on the VMM side. Now we want to implement it directly in the
> >guest kernel to reduce modifications to the VMMs. There are some
> >measurements in [0]; however, the comparison is between vmlinux and
> >bzImage.
> >
> >In my test environment, compared to the original direct kernel booting,
> >it would add 2ms for my test configuration [1] based on the Kata
> >Containers repository due to the self-relocation phase. Booting from
> >bzImage does not affect the boot time, as it simply inserts
> >'vmlinux.relocs' into vmlinux, resulting in no change to the total size.
> >The decompression time should also not be affected; I didn't notice any
> >difference when measuring the decompression().
> >
> >[0]: https://dl.acm.org/doi/epdf/10.1145/3492321.3519578
> >[1]: https://raw.githubusercontent.com/virt-pvm/misc/refs/heads/main/pvm-guest-6.12.33.config
> >
> >Thanks!
> >
> >> Thanks! 
> 
> Didn't you say that that was the reason for this? I'm confused now.

Maybe my expression is not clear. :(
Let me reorganize my thoughts. If you want to enable KASLR for the
guest, this patch makes booting faster, as the guest is now booting from
vmlinux instead of bzImage. However, if you don’t need KASLR for the
guest, you can continue booting from vmlinux, so the newly added
relocation process may introduce a slight overhead (due to command line
parsing), which is what I meant when I said it slows down the booting
from vmlinux. I'm not sure if you need KASLR in your case.

Thanks!