Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
Hi Junho,
See answers below [OD]
Regards, Olivier.
________________________________ From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 https://developer.arm.com/documentation/ka006421/1-0) Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
________________________________ From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards, Olivier.
________________________________ From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 https://developer.arm.com/documentation/ka006421/1-0) Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have! __________________________________________________________________
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier. __________________________________________________________________
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello, I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution. I have some questions about Hafnium for Secure EL2 extension. (1) Why do you consider VHE as default option? (I saw it in arch_mm_init) According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE. Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 [1]https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI. Why doesn't SPMD forward other commands such as CPU_SUSPEND? In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt? I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not. If you're not the right person, please forward this mail to the right person. Thanks! Best Regards, Junho Choi [cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy
MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE5MDMwNzMxZXBjbXMycDNj ZjkxMzgxYTNhNjBkMjVlMDE3Mjk4NjNhNGJiMjY3MSZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
References
Hi Junho Choi,
* Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
Hafnium used to support HCR_EL2.E2H=0 but I assume this configuration is getting deprecated in future (and likely to disappear), refer to [1]. From Armv9.6 FEAT_SRMASK is mandatory, implying FEAT_E2H0 is not implemented, implying that if FEAT_AA64EL2 is implemented then FEAT_VHE is implemented and finally HCR_EL2.E2H=RES1. KVM already did this change because of certain cores already forcing this bit, see [2].
* Can I run Hafnium with non-VHE if I want?
It depends what is meant by 'non-VHE', KVM relates to nVHE as VHE enabled (E2H=1) + linux running in guest mode at NS-EL1. If it means VHE disabled (E2H=0) it may be possible with hafnium although completely untested nowadays, and I don't see a good reason for doing this, apart from if the hardware doesn't support Armv8.1 FEAT_VHE which is unlikely if an hypervisor is present (aka FEAT_AA64EL2 is implemented). That said, note an hypervisor may still use E2H=0 in normal world, while S-EL2 uses E2H=1 in secure world, the bit flip is managed during world switching.
* I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
Yes EL3 SPMC may support indeed. This is a gap not handled with hafnium, but it could fixed, I believe this might not be a large amount of work at least for supporting with S-EL1 MP SPs. The challenge may be with the testing. Also the case of S-EL0 SPs (single vCPU) is much more blurry.
Regards, Olivier.
[1] https://developer.arm.com/documentation/109697/2025_09/Feature-descriptions/... [2] https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/
________________________________ From: Junho Choi junhosj.choi@samsung.com Sent: 19 November 2025 04:07 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
________________________________
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier.
________________________________
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[cid:cafe_image_0@s-core.co.kr]
[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=junhosj.cho...]
Hi Olivier,
You mean Arm architecture's default virtualization option is VHE which supports hosted hypervisor(type-2) effectively, is it right?
In my understanding, type-2 is that host OS takes a role as hypervisor, so type 1 is more secure in mobile AP environment because we can compromise host OS easily.
Why Arm architecture adopted VHE as default? Is there any pros in term of HW architecure?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-19 19:27 (GMT+9)
Title : Re: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi, * Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
Hafnium used to support HCR_EL2.E2H=0 but I assume this configuration is getting deprecated in future (and likely to disappear), refer to [1]. From Armv9.6 FEAT_SRMASK is mandatory, implying FEAT_E2H0 is not implemented, implying that if FEAT_AA64EL2 is implemented then FEAT_VHE is implemented and finally HCR_EL2.E2H=RES1.
KVM already did this change because of certain cores already forcing this bit, see [2]. * Can I run Hafnium with non-VHE if I want?
It depends what is meant by 'non-VHE', KVM relates to nVHE as VHE enabled (E2H=1) + linux running in guest mode at NS-EL1.
If it means VHE disabled (E2H=0) it may be possible with hafnium although completely untested nowadays, and I don't see a good reason for doing this, apart from if the hardware doesn't support Armv8.1 FEAT_VHE which is unlikely if an hypervisor is present (aka FEAT_AA64EL2 is implemented). That said, note an hypervisor may still use E2H=0 in normal world, while S-EL2 uses E2H=1 in secure world, the bit flip is managed during world switching. * I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
Yes EL3 SPMC may support indeed. This is a gap not handled with hafnium, but it could fixed, I believe this might not be a large amount of work at least for supporting with S-EL1 MP SPs. The challenge may be with the testing. Also the case of S-EL0 SPs (single vCPU) is much more blurry.
Regards,
Olivier.
[1] [1]https://developer.arm.com/documentation/109697/2025_09/Feature-descr iptions/The-Armv9-6-architecture-extension
[2] [2]https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/ __________________________________________________________________
From: Junho Choi junhosj.choi@samsung.com Sent: 19 November 2025 04:07 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier.
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 [3]https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[http://kor2.samsung.net/mail/rest/v1/files/image/download/ATT00001.png ?1=1&filepath=/SHARED/TEMP/ML/image/O/20251120/1_236186_cafe_image_0@s- core.co.kr_0_Olivier.Deprez&user=Olivier.Deprez&partno=0&folderId=1&seq id=236186&contentType=image%2Fpng]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy
MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[cid:cafe_image_0@s-core.co.kr]
[cid:20251120062935_0@epcms2p]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTIwMDYyOTM1ZXBjbXMycDVj OGUzYjFmNjBlODYwNDAzOWY5ZGViMDI3Y2M5OTdlZSZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
References
1. https://developer.arm.com/documentation/109697/2025_09/Feature-descriptions/... 2. https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/ 3. https://developer.arm.com/documentation/ka006421/1-0
Hi Junho Choi,
I believe you should view VHE as a superset. This means VHE enabled (HCR_EL2.E2H=1 as default) still permits implementing both Type-1 and Type-2 hypervisors. The difference will be whether the lower EL runs in host or guest mode depending on HCR_EL2.TGE. For the cases we are concerned about HCR_EL2.E2H=0 or HCR_EL2.{E2H,TGE}={1,1} are equivalent. See more details in [1].
In a way Hafnium in the secure world acts as a Type-1 hypervisor for running one or multiple S-EL1 secure OSes on top of it (with HCR_EL2.{E2H,TGE}={1,1}). It also has the ability to run S-EL0 only secure applications with HCR_EL2.{E2H,TGE}={1,0} in which case S-EL1 is discarded.
Regards, Olivier.
[1] https://developer.arm.com/documentation/102142/0100/Virtualization-host-exte...
________________________________ From: Junho Choi junhosj.choi@samsung.com Sent: 20 November 2025 07:29 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
You mean Arm architecture's default virtualization option is VHE which supports hosted hypervisor(type-2) effectively, is it right?
In my understanding, type-2 is that host OS takes a role as hypervisor, so type 1 is more secure in mobile AP environment because we can compromise host OS easily.
Why Arm architecture adopted VHE as default? Is there any pros in term of HW architecure?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-19 19:27 (GMT+9)
Title : Re: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi,
* Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
Hafnium used to support HCR_EL2.E2H=0 but I assume this configuration is getting deprecated in future (and likely to disappear), refer to [1]. From Armv9.6 FEAT_SRMASK is mandatory, implying FEAT_E2H0 is not implemented, implying that if FEAT_AA64EL2 is implemented then FEAT_VHE is implemented and finally HCR_EL2.E2H=RES1.
KVM already did this change because of certain cores already forcing this bit, see [2].
* Can I run Hafnium with non-VHE if I want?
It depends what is meant by 'non-VHE', KVM relates to nVHE as VHE enabled (E2H=1) + linux running in guest mode at NS-EL1.
If it means VHE disabled (E2H=0) it may be possible with hafnium although completely untested nowadays, and I don't see a good reason for doing this, apart from if the hardware doesn't support Armv8.1 FEAT_VHE which is unlikely if an hypervisor is present (aka FEAT_AA64EL2 is implemented). That said, note an hypervisor may still use E2H=0 in normal world, while S-EL2 uses E2H=1 in secure world, the bit flip is managed during world switching.
* I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
Yes EL3 SPMC may support indeed. This is a gap not handled with hafnium, but it could fixed, I believe this might not be a large amount of work at least for supporting with S-EL1 MP SPs. The challenge may be with the testing. Also the case of S-EL0 SPs (single vCPU) is much more blurry.
Regards,
Olivier.
[1] https://developer.arm.com/documentation/109697/2025_09/Feature-descriptions/...
[2] https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/
________________________________
From: Junho Choi junhosj.choi@samsung.com Sent: 19 November 2025 04:07 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier.
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[http://kor2.samsung.net/mail/rest/v1/files/image/download/ATT00001.png?1=1&a...]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[cid:cafe_image_0@s-core.co.kr]
[cid:20251120062935_0@epcms2p]
[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=junhosj.cho...]
Hi Olivier,
Did you mean the current Hafnium is type-1 hypervisor even if it has set HCR_EL2.{E2H,TGE}={1,1}?
If so, "VHE enabled means type-2 hypervisor" is incorrect, is it right?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-20 16:54 (GMT+9)
Title : Re: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi,
I believe you should view VHE as a superset.
This means VHE enabled (HCR_EL2.E2H=1 as default) still permits implementing both Type-1 and Type-2 hypervisors.
The difference will be whether the lower EL runs in host or guest mode depending on HCR_EL2.TGE.
For the cases we are concerned about HCR_EL2.E2H=0 or HCR_EL2.{E2H,TGE}={1,1} are equivalent.
See more details in [1].
In a way Hafnium in the secure world acts as a Type-1 hypervisor for running one or multiple S-EL1 secure OSes on top of it (with HCR_EL2.{E2H,TGE}={1,1}).
It also has the ability to run S-EL0 only secure applications with HCR_EL2.{E2H,TGE}={1,0} in which case S-EL1 is discarded.
Regards,
Olivier.
[1] [1]https://developer.arm.com/documentation/102142/0100/Virtualization-h ost-extensions __________________________________________________________________
From: Junho Choi junhosj.choi@samsung.com Sent: 20 November 2025 07:29 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
You mean Arm architecture's default virtualization option is VHE which supports hosted hypervisor(type-2) effectively, is it right?
In my understanding, type-2 is that host OS takes a role as hypervisor, so type 1 is more secure in mobile AP environment because we can compromise host OS easily.
Why Arm architecture adopted VHE as default? Is there any pros in term of HW architecure?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-19 19:27 (GMT+9)
Title : Re: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi, * Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
Hafnium used to support HCR_EL2.E2H=0 but I assume this configuration is getting deprecated in future (and likely to disappear), refer to [1]. From Armv9.6 FEAT_SRMASK is mandatory, implying FEAT_E2H0 is not implemented, implying that if FEAT_AA64EL2 is implemented then FEAT_VHE is implemented and finally HCR_EL2.E2H=RES1.
KVM already did this change because of certain cores already forcing this bit, see [2]. * Can I run Hafnium with non-VHE if I want?
It depends what is meant by 'non-VHE', KVM relates to nVHE as VHE enabled (E2H=1) + linux running in guest mode at NS-EL1.
If it means VHE disabled (E2H=0) it may be possible with hafnium although completely untested nowadays, and I don't see a good reason for doing this, apart from if the hardware doesn't support Armv8.1 FEAT_VHE which is unlikely if an hypervisor is present (aka FEAT_AA64EL2 is implemented). That said, note an hypervisor may still use E2H=0 in normal world, while S-EL2 uses E2H=1 in secure world, the bit flip is managed during world switching. * I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
Yes EL3 SPMC may support indeed. This is a gap not handled with hafnium, but it could fixed, I believe this might not be a large amount of work at least for supporting with S-EL1 MP SPs. The challenge may be with the testing. Also the case of S-EL0 SPs (single vCPU) is much more blurry.
Regards,
Olivier.
[1] [2]https://developer.arm.com/documentation/109697/2025_09/Feature-descr iptions/The-Armv9-6-architecture-extension
[2] [3]https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/
From: Junho Choi junhosj.choi@samsung.com Sent: 19 November 2025 04:07 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier.
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 [4]https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[http://kor2.samsung.net/mail/rest/v1/files/image/download/ATT00001.png ?1=1&filepath=/SHARED/TEMP/ML/image/O/20251120/1_236186_cafe_image_0@s- core.co.kr_0_Olivier.Deprez&user=Olivier.Deprez&partno=0&folderId=1&seq id=236186&contentType=image%2Fpng]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy
MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[cid:cafe_image_0@s-core.co.kr]
[cid:cafe_image_0@s-core.co.kr]
[cid:20251120123021_0@epcms2p]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTIwMTIzMDIxZXBjbXMycDQ4 MDA0NmZiODU5ODQyNzAzNTU5NTM3ZWIxOTdiZGQ5OCZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
References
1. https://developer.arm.com/documentation/102142/0100/Virtualization-host-exte... 2. https://developer.arm.com/documentation/109697/2025_09/Feature-descriptions/... 3. https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/ 4. https://developer.arm.com/documentation/ka006421/1-0
Hi,
* Did you mean the current Hafnium is type-1 hypervisor even if it has set HCR_EL2.{E2H,TGE}={1,1}?
Yes, this is the way a Type-1 hypervisor support EL1 guests when VHE is implemented and enabled.
* VHE enabled means type-2 hypervisor
VHE helps improving the performance of Type-2 hypervisors but VHE enabled doesn't mean you're forced to implement a Type-2 hypervisor. You can implement a Type-1 hypervisor with VHE implemented and enabled.
Regards, Olivier.
________________________________ From: Junho Choi junhosj.choi@samsung.com Sent: 20 November 2025 13:30 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(6) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Did you mean the current Hafnium is type-1 hypervisor even if it has set HCR_EL2.{E2H,TGE}={1,1}?
If so, "VHE enabled means type-2 hypervisor" is incorrect, is it right?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-20 16:54 (GMT+9)
Title : Re: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi,
I believe you should view VHE as a superset.
This means VHE enabled (HCR_EL2.E2H=1 as default) still permits implementing both Type-1 and Type-2 hypervisors.
The difference will be whether the lower EL runs in host or guest mode depending on HCR_EL2.TGE.
For the cases we are concerned about HCR_EL2.E2H=0 or HCR_EL2.{E2H,TGE}={1,1} are equivalent.
See more details in [1].
In a way Hafnium in the secure world acts as a Type-1 hypervisor for running one or multiple S-EL1 secure OSes on top of it (with HCR_EL2.{E2H,TGE}={1,1}).
It also has the ability to run S-EL0 only secure applications with HCR_EL2.{E2H,TGE}={1,0} in which case S-EL1 is discarded.
Regards,
Olivier.
[1] https://developer.arm.com/documentation/102142/0100/Virtualization-host-exte...
________________________________
From: Junho Choi junhosj.choi@samsung.com Sent: 20 November 2025 07:29 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
You mean Arm architecture's default virtualization option is VHE which supports hosted hypervisor(type-2) effectively, is it right?
In my understanding, type-2 is that host OS takes a role as hypervisor, so type 1 is more secure in mobile AP environment because we can compromise host OS easily.
Why Arm architecture adopted VHE as default? Is there any pros in term of HW architecure?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-19 19:27 (GMT+9)
Title : Re: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi,
* Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
Hafnium used to support HCR_EL2.E2H=0 but I assume this configuration is getting deprecated in future (and likely to disappear), refer to [1]. From Armv9.6 FEAT_SRMASK is mandatory, implying FEAT_E2H0 is not implemented, implying that if FEAT_AA64EL2 is implemented then FEAT_VHE is implemented and finally HCR_EL2.E2H=RES1.
KVM already did this change because of certain cores already forcing this bit, see [2].
* Can I run Hafnium with non-VHE if I want?
It depends what is meant by 'non-VHE', KVM relates to nVHE as VHE enabled (E2H=1) + linux running in guest mode at NS-EL1.
If it means VHE disabled (E2H=0) it may be possible with hafnium although completely untested nowadays, and I don't see a good reason for doing this, apart from if the hardware doesn't support Armv8.1 FEAT_VHE which is unlikely if an hypervisor is present (aka FEAT_AA64EL2 is implemented). That said, note an hypervisor may still use E2H=0 in normal world, while S-EL2 uses E2H=1 in secure world, the bit flip is managed during world switching.
* I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
Yes EL3 SPMC may support indeed. This is a gap not handled with hafnium, but it could fixed, I believe this might not be a large amount of work at least for supporting with S-EL1 MP SPs. The challenge may be with the testing. Also the case of S-EL0 SPs (single vCPU) is much more blurry.
Regards,
Olivier.
[1] https://developer.arm.com/documentation/109697/2025_09/Feature-descriptions/...
[2] https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/
From: Junho Choi junhosj.choi@samsung.com Sent: 19 November 2025 04:07 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier.
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[http://kor2.samsung.net/mail/rest/v1/files/image/download/ATT00001.png?1=1&a...]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[cid:cafe_image_0@s-core.co.kr]
[cid:cafe_image_0@s-core.co.kr]
[cid:20251120123021_0@epcms2p]
[http://ext.samsung.net/mail/ext/v1/external/status/update?userid=junhosj.cho...]
Hi Olivier,
Thanks for your answer.
I appreciate your guidance.
Have a good day :) Best Regards, Junho Choi
--------- Original Message --------- Sender : Olivier Deprez Olivier.Deprez@arm.com Date : 2025-11-21 00:09 (GMT+9) Title : RE:(7) [Hafnium] Questions about Hafnium as S-EL2
Hi,
* Did you mean the current Hafnium is type-1 hypervisor even if it has set HCR_EL2.{E2H,TGE}={1,1}?
Yes, this is the way a Type-1 hypervisor support EL1 guests when VHE is implemented and enabled.
* VHE enabled means type-2 hypervisor
VHE helps improving the performance of Type-2 hypervisors but VHE enabled doesn't mean you're forced to implement a Type-2 hypervisor.
You can implement a Type-1 hypervisor with VHE implemented and enabled.
Regards,
Olivier. __________________________________________________________________
From: Junho Choi junhosj.choi@samsung.com Sent: 20 November 2025 13:30 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(6) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Did you mean the current Hafnium is type-1 hypervisor even if it has set HCR_EL2.{E2H,TGE}={1,1}?
If so, "VHE enabled means type-2 hypervisor" is incorrect, is it right?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-20 16:54 (GMT+9)
Title : Re: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi,
I believe you should view VHE as a superset.
This means VHE enabled (HCR_EL2.E2H=1 as default) still permits implementing both Type-1 and Type-2 hypervisors.
The difference will be whether the lower EL runs in host or guest mode depending on HCR_EL2.TGE.
For the cases we are concerned about HCR_EL2.E2H=0 or HCR_EL2.{E2H,TGE}={1,1} are equivalent.
See more details in [1].
In a way Hafnium in the secure world acts as a Type-1 hypervisor for running one or multiple S-EL1 secure OSes on top of it (with HCR_EL2.{E2H,TGE}={1,1}).
It also has the ability to run S-EL0 only secure applications with HCR_EL2.{E2H,TGE}={1,0} in which case S-EL1 is discarded.
Regards,
Olivier.
[1] [1]https://developer.arm.com/documentation/102142/0100/Virtualization-h ost-extensions __________________________________________________________________
From: Junho Choi junhosj.choi@samsung.com Sent: 20 November 2025 07:29 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(4) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
You mean Arm architecture's default virtualization option is VHE which supports hosted hypervisor(type-2) effectively, is it right?
In my understanding, type-2 is that host OS takes a role as hypervisor, so type 1 is more secure in mobile AP environment because we can compromise host OS easily.
Why Arm architecture adopted VHE as default? Is there any pros in term of HW architecure?
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-19 19:27 (GMT+9)
Title : Re: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Junho Choi, * Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
Hafnium used to support HCR_EL2.E2H=0 but I assume this configuration is getting deprecated in future (and likely to disappear), refer to [1]. From Armv9.6 FEAT_SRMASK is mandatory, implying FEAT_E2H0 is not implemented, implying that if FEAT_AA64EL2 is implemented then FEAT_VHE is implemented and finally HCR_EL2.E2H=RES1.
KVM already did this change because of certain cores already forcing this bit, see [2]. * Can I run Hafnium with non-VHE if I want?
It depends what is meant by 'non-VHE', KVM relates to nVHE as VHE enabled (E2H=1) + linux running in guest mode at NS-EL1.
If it means VHE disabled (E2H=0) it may be possible with hafnium although completely untested nowadays, and I don't see a good reason for doing this, apart from if the hardware doesn't support Armv8.1 FEAT_VHE which is unlikely if an hypervisor is present (aka FEAT_AA64EL2 is implemented). That said, note an hypervisor may still use E2H=0 in normal world, while S-EL2 uses E2H=1 in secure world, the bit flip is managed during world switching. * I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
Yes EL3 SPMC may support indeed. This is a gap not handled with hafnium, but it could fixed, I believe this might not be a large amount of work at least for supporting with S-EL1 MP SPs. The challenge may be with the testing. Also the case of S-EL0 SPs (single vCPU) is much more blurry.
Regards,
Olivier.
[1] [2]https://developer.arm.com/documentation/109697/2025_09/Feature-descr iptions/The-Armv9-6-architecture-extension
[2] [3]https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/
From: Junho Choi junhosj.choi@samsung.com Sent: 19 November 2025 04:07 To: Olivier Deprez Olivier.Deprez@arm.com; hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: RE:(2) [Hafnium] Questions about Hafnium as S-EL2
Hi Olivier,
Thanks for your answer.
But I want to ask more about (1) and (2).
Please see below [JC].
Best Regards,
Junho Choi
--------- Original Message ---------
Sender : Olivier Deprez Olivier.Deprez@arm.com
Date : 2025-11-18 17:18 (GMT+9)
Title : Re: [Hafnium] Questions about Hafnium as S-EL2
BTW I missed to mention, answers below reflect the current state of the project, but we're happy to hear and discuss alternatives or proposals you may have!
From: Olivier Deprez Olivier.Deprez@arm.com Sent: 18 November 2025 09:14 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org; junhosj.choi@samsung.com junhosj.choi@samsung.com Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: Re: [Hafnium] Questions about Hafnium as S-EL2
Hi Junho,
See answers below [OD]
Regards,
Olivier.
From: Junho Choi junhosj.choi@samsung.com on behalf of Junho Choi via Hafnium hafnium@lists.trustedfirmware.org Sent: 18 November 2025 06:51 To: hafnium@lists.trustedfirmware.org hafnium@lists.trustedfirmware.org Cc: Jungtae Kim jt1217.kim@samsung.com; Mankyum Kim mankyum.kim@samsung.com; Keunhong Choi kn_hong.choi@samsung.com; Daero Lee daero_le.lee@samsung.com Subject: [Hafnium] Questions about Hafnium as S-EL2
Hello,
I'm Junho Choi in Samsung S.LSI and I've been working on virtualization solution.
I have some questions about Hafnium for Secure EL2 extension.
(1) Why do you consider VHE as default option? (I saw it in arch_mm_init)
According to Hafnium init sequence, has_vhe_support always returns true as long as ARM cores have support for VHE.
Is there any requirements that Hafnium should support VHE?
[OD] In a way, yes. It is assumed most if not all Armv8.1 (and greater) platforms support FEAT_VHE. Moreover FEAT_SEL2 is an Armv8.4 feature hence FEAT_VHE is assumed to be supported. In future, certain implementations will make FEAT_VHE mandatory (aka HCR_EL2.E2H=RES1 [4]https://developer.arm.com/documentation/ka006421/1-0)
Hafnium supports two secure partitions types leveraging FEAT_VHE: S-EL1 multiprocessor SPs (running in VHE guest) and S-EL0 uniprocessor SPs (running in VHE host).
[JC] I have two additional questions.
- Why is the VHE default configuration? As far as I know, most of non-seucre hypervisor has run as non-VHE (except KVM).
- Can I run Hafnium with non-VHE if I want?
(2) TF-A's SPMD has only forwarded svc_on_finish and svc_off of PSCI.
Why doesn't SPMD forward other commands such as CPU_SUSPEND?
In case of the CPU_SUSPEND, secure EL2 or SP may need to know when physcial CPU turns off.
[OD] This is a debt. This scenario has never been really exercised so far. The only caveat is that entering a SP on each CPU_SUSPEND event happening very frequently might turn to be very costly in term of world/context switching. Also note conceptually vCPUs are exposed to secure partitions. Secure partition might not have all visibilty on the physical CPU state, or require changes in Hafnium itself.
[JC] I understand about CPU_SUSPEND. But, I can see that el3_spmc registers svc_suspend ops and it looks like to send to SP. Is it because el3_spmc has support for only single SP? Otherwise, is there another reason?
(3) Why do you set HCR_EL2.VI and VF to handle virtual interrupt?
I think we have an another method to use List registers (ICH_LRn_EL2) to inject virtual interrup to guest (SP).
[OD] This is a design choice. Hafnium exposes an para virtualized interrupt controller interface. The use of GICv3 vcpu interface and list registers has been investigated but concluded to be very complex to manage.
I'm not sure whether asking you is proper or not.
If you're not the right person, please forward this mail to the right person.
Thanks!
Best Regards,
Junho Choi
[http://kor2.samsung.net/mail/rest/v1/files/image/download/ATT00001.png ?1=1&filepath=/SHARED/TEMP/ML/image/O/20251120/1_236186_cafe_image_0@s- core.co.kr_0_Olivier.Deprez&user=Olivier.Deprez&partno=0&folderId=1&seq id=236186&contentType=image%2Fpng]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTE4MDU1MTQ0ZXBjbXMycDUy
MjBlZTFkOGFiNGIxNGRkYzQ1MTNiN2E2ZTA3NzM2MyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__] -- Hafnium mailing list -- hafnium@lists.trustedfirmware.org To unsubscribe send an email to hafnium-leave@lists.trustedfirmware.org
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTIwMTIzMDIxZXBjbXMycDQ4 MDA0NmZiODU5ODQyNzAzNTU5NTM3ZWIxOTdiZGQ5OCZyZWNpcGllbnRBZGRyZXNzPU9saXZ pZXIuRGVwcmV6QGFybS5jb20_]
[cid:cafe_image_0@s-core.co.kr]
[update?userid=junhosj.choi&do=bWFpbElEPTIwMjUxMTIzMjIxNDI1ZXBjbXMycDJh MGEwNGEyYzM3NDU1MTc5NmQzZDcwNmVhMGVmMjliNyZyZWNpcGllbnRBZGRyZXNzPWhhZm5 pdW1AbGlzdHMudHJ1c3RlZGZpcm13YXJlLm9yZw__]
References
1. https://developer.arm.com/documentation/102142/0100/Virtualization-host-exte... 2. https://developer.arm.com/documentation/109697/2025_09/Feature-descriptions/... 3. https://lore.kernel.org/all/20240122181344.258974-8-maz@kernel.org/ 4. https://developer.arm.com/documentation/ka006421/1-0
hafnium@lists.trustedfirmware.org
-
Junho Choi -
Olivier Deprez