elfloader: add support for PSCI functions via HVC #239

Ivan-Velickovic · 2025-10-23T13:03:00Z

My understanding is the HVC ABI is the exact same as the SMC one, it's just a difference with exception levels.

Also adds a commit to automatically add the right -smp flags with the generated simulate scripts.

Draft because I did this very quickly and need to review my own changes more.

So far I have tested that SMP/uni-core QEMU works and that I haven't broken PSCI SVC functionality by testing SMP on the Odroid-C4.

Ivan-Velickovic · 2025-10-23T13:03:37Z

cmake-tool/simulate_scripts/simulate.py

                        help="QEMU CPU", default="@QEMU_SIM_CPU@")
    parser.add_argument('-o', '--cpu-opt', dest='qemu_sim_cpu_opt', type=str,
                        help="QEMU CPU Options", default="@QEMU_SIM_CPU_OPT@")
+    parser.add_argument('--smp', dest='qemu_sim_smp', type=str,


All the other main arguments have a single letter variant, -s is already taken though so I didn't know what to put here.

Maybe -j, like make does?

elfloader-tool/src/arch-arm/psci.c

Ivan-Velickovic · 2025-10-23T13:08:41Z

elfloader-tool/src/arch-arm/armv/armv7-a/32/smc.S

I should investigate into HVC on 32-bit ARM.

Seems to be the same as for 64-bit Arm.

I initially tried that but it failed for 32-bit ARM on QEMU. Will have to debug.

Ivan-Velickovic · 2025-10-23T13:11:28Z

cmake-tool/helpers/simulation.cmake

    set(sim_cpu_opt "")
    set(sim_machine "")
    set(qemu_sim_extra_args "")
+    set(sim_smp "${KernelMaxNumNodes}")


This will apply to all simulation targets, but I have only tested ARM.

If the Qemu argument is the same, it should work. If not, we're not worse off than before.

It is the same across all architectures so yes it should be fine.

Indanz · 2025-10-23T16:06:05Z

Considering you want to turn on a real CPU core, I don't see why you would need to use a HVC call instead of a SMC call for that. HCV is to call to a hypervisor running in EL2, SMC is to call into EL3. So except if for some reason SMC just fails and HVC is redirected to EL3, I don't see how using HVC can work while SMC doesn't. Is this some Qemu quirk or am I missing something?

midnightveil · 2025-10-23T21:59:04Z

Yeah, I think this might be a weird QEMU quirk. But given how little was needed to fix it...

However there are a few (but not many) boards with device trees that specify that they want HVC calls for PSCI, e.g. https://elixir.bootlin.com/linux/v6.17.4/source/arch/arm64/boot/dts/qcom/msm8994.dtsi#L178. So it's not unreasonable for the device tree to ask for this...

Ivan-Velickovic · 2025-10-24T05:17:21Z

Is this some Qemu quirk or am I missing something?

I don't know why just doing an smc instead does not work, I tried it but it failed to turn on any other CPUs.

I do not know why QEMU has this restriction, I am yet to look into it.

Ivan-Velickovic · 2025-10-24T05:19:07Z

Perhaps this clears things up:
https://github.com/qemu/qemu/blob/88b1716a407459c8189473e4667653cb8e4c3df7/hw/arm/virt.c#L2265-L2281

Ivan-Velickovic · 2025-11-04T09:00:07Z

This is ready for review now. I have added more details in the commit message for the motivation and why this is needed in the first place.

I attempted to get 32-bit ARM working but ran into two problems:

At least for the PSCI version that QEMU expects, the SMC/HVC function IDs are incorrect for 32-bit. E.g for SMC_FID_CPU_ON it is 0x80000003 instead of 0x84000003.
The function IDs were easy to fix, which then lead to all the CPUs being booted and the kernel started executing, but never dropped to user space.

This is the log I got:

ELF-loader started on CPU: ARM Ltd. Cortex-A15 r2p1
  paddr=[40454000..4076104b]
No DTB passed in from boot loader.
Looking for DTB in CPIO archive...found at 4049886c.
Loaded DTB from 4049886c.
   paddr=[4004c000..4004dfff]
ELF-loading image 'kernel' to 40000000
  paddr=[40000000..4004bfff]
  vaddr=[a0000000..a004bfff]
  virt_entry=a0000000
ELF-loading image 'rootserver' to 4004e000
  paddr=[4004e000..40433fff]
  vaddr=[10000..3f5fff]
  virt_entry=1d77c
Boot cpu id = 0x0, index=0
Core 1 is up with logic id 1
Core 2 is up with logic id 2
Core 3 is up with logic id 3
Enabling MMU and paging
Jumping to kernel-image entry point...

Bootstrapping kernel
available phys memory regions: 1
  [40000000..80000000)
reserved virt address space regions: 4
  [a0000000..a004c000)
  [a004c000..a004de8e)
  [a004e000..a0434000)
  [ff000000..ff100000)

I don't know if I have time to debug the 32-bit ARM case, I can type up more details and post it in an issue.

Is it possible to get this merged without 32-bit support?

The motivation for this change is that currently if the elfloader is trying to boot multiple CPUs for an SMP configuration of seL4, it will fail unless the PSCI method is SVC. The only other possible PSCI method that is possible is HVC, which can occur when the system is being virtualised by something like QEMU and is executing at EL1. For QEMU, unless it is running with virtualisation explicitly enabled (`virtualization=on`), it will default to accepting only the HVC PSCI method. More details are available in comments in the QEMU source [1]. My understanding is the HVC ABI is the exact same as the SMC one, it's just a difference with exception levels. [1]: https://github.com/qemu/qemu/blob/88b1716a407459c8189473e4667653cb8e4c3df7/hw/arm/virt.c#L2265-L2281. Signed-off-by: Ivan Velickovic <[email protected]>

Signed-off-by: Ivan Velickovic <[email protected]>

Indanz

I would prefer working arm32 support, but otherwise looks fine.

Indanz · 2025-11-05T15:44:11Z

cmake-tool/simulate_scripts/simulate.py

                        help="QEMU CPU", default="@QEMU_SIM_CPU@")
    parser.add_argument('-o', '--cpu-opt', dest='qemu_sim_cpu_opt', type=str,
                        help="QEMU CPU Options", default="@QEMU_SIM_CPU_OPT@")
+    parser.add_argument('--smp', dest='qemu_sim_smp', type=str,


Maybe -j, like make does?

Indanz · 2025-11-05T15:45:18Z

cmake-tool/helpers/simulation.cmake

    set(sim_cpu_opt "")
    set(sim_machine "")
    set(qemu_sim_extra_args "")
+    set(sim_smp "${KernelMaxNumNodes}")


If the Qemu argument is the same, it should work. If not, we're not worse off than before.

Indanz · 2025-11-05T16:07:33Z

I attempted to get 32-bit ARM working but ran into two problems:

1. At least for the PSCI version that QEMU expects, the SMC/HVC function IDs are incorrect for 32-bit. E.g for `SMC_FID_CPU_ON` it is `0x80000003` instead of `0x84000003`.

That doesn't make any sense, is this another Qemu quirk?

Please just add the 32-bit support and ignore the problem for now (so no FID work-arounds either). Maybe add a printf that it seems broken on Qemu, but trying anyway.

Ivan-Velickovic · 2025-11-05T23:47:30Z

That doesn't make any sense, is this another Qemu quirk?

I was looking at this PSCI specification (DEN0022F.b_Power_State_Coordination_Interface). Section 5.1.4 says the function ID for SMC32 is 0x84000003, but the elfloader code has it as 0x80000003.

Please just add the 32-bit support and ignore the problem for now (so no FID work-arounds either). Maybe add a printf that it seems broken on Qemu, but trying anyway.

Sure.

Indanz · 2025-11-06T00:04:30Z

That doesn't make any sense, is this another Qemu quirk?

I was looking at this PSCI specification (DEN0022F.b_Power_State_Coordination_Interface). Section 5.1.4 says the function ID for SMC32 is 0x84000003, but the elfloader code has it as 0x80000003.

Oh, that's just wrong. Bit 30 determines whether the calling convention is 32 or 64 bits, but Elfloader is using the 32 bit calling convention on 64-bit, so all codes should be the same.

Note that this does not work for 32-bit ARM, at least when tested on QEMU with: ../init-build.sh -DPLATFORM=qemu-arm-virt -DAARCH32=1 -DSMP=1 See [1] for details. [1]: seL4#239 (comment). Signed-off-by: Ivan Velickovic <[email protected]>

Ivan-Velickovic commented Oct 23, 2025

View reviewed changes

elfloader-tool/src/arch-arm/psci.c Show resolved Hide resolved

Ivan-Velickovic force-pushed the hvc_support branch 2 times, most recently from 8a53cb9 to cea7513 Compare October 23, 2025 13:07

Ivan-Velickovic commented Oct 23, 2025

View reviewed changes

Ivan-Velickovic force-pushed the hvc_support branch from cea7513 to d415709 Compare October 23, 2025 13:25

Ivan-Velickovic marked this pull request as ready for review November 4, 2025 08:55

Ivan-Velickovic force-pushed the hvc_support branch from d415709 to aa72f55 Compare November 4, 2025 08:55

Ivan-Velickovic added 2 commits November 4, 2025 20:01

cmake-tool: support QEMU simulation for SMP

80ae668

Signed-off-by: Ivan Velickovic <[email protected]>

Ivan-Velickovic force-pushed the hvc_support branch from aa72f55 to 80ae668 Compare November 4, 2025 09:01

Indanz approved these changes Nov 5, 2025

View reviewed changes

elfloader: allow HVC PSCI on 32-bit ARM, broken

8c7a9b4

Note that this does not work for 32-bit ARM, at least when tested on QEMU with: ../init-build.sh -DPLATFORM=qemu-arm-virt -DAARCH32=1 -DSMP=1 See [1] for details. [1]: seL4#239 (comment). Signed-off-by: Ivan Velickovic <[email protected]>

elfloader: add support for PSCI functions via HVC #239

Are you sure you want to change the base?

elfloader: add support for PSCI functions via HVC #239

Uh oh!

Conversation

Ivan-Velickovic commented Oct 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Indanz commented Oct 23, 2025

Uh oh!

midnightveil commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ivan-Velickovic commented Oct 24, 2025

Uh oh!

Ivan-Velickovic commented Oct 24, 2025

Uh oh!

Ivan-Velickovic commented Nov 4, 2025

Uh oh!

Indanz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Indanz commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ivan-Velickovic commented Nov 5, 2025

Uh oh!

Indanz commented Nov 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

midnightveil commented Oct 23, 2025 •

edited

Loading

Indanz commented Nov 5, 2025 •

edited

Loading