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