On Thu, 17 Dec 2020 at 17:44, Achin Gupta via Hafnium < hafnium@lists.trustedfirmware.org> wrote:
Hi Raghu,
On Tue, Dec 15, 2020 at 09:41:05AM -0800, raghu.ncstate@icloud.com wrote:
Hi Olivier,
[snip]
Hi Achin,
Question for you. I interpreted the FF-A 1.0 spec as "requiring" VHE for S-EL0 partitions, based on options 1 and 2 in section 2.2.1, since
option 2
does not mention S-EL0 partitions. Can you confirm this is the case? As I was thinking through this, it seems like we might be able to pull off EL0 partitions without using VHE, i.e by using HCR_EL2.E2H = 0 and HCR_EL2.TGE=1. HCR_EL2.TGE is present even on ARMv8.0 architecture and removes
dependence
on VHE, and effectively removes the necessity for this patch series. However, I'd like to understand your thoughts on why VHE is suggested in
the
spec and if hafnium should use VHE for S-EL0 partitions or if hafnium can use the approach suggested above.
The intent in the spec is not to mandate VHE for S-EL0 SPs. We can add a clarification if that helps.
The intent in the spec is to highlight that VHE is applicable to S-EL0 SPs only.
With VHE, the S-EL1 exception level disappears. The SPMC can only have awareness of S-EL0 SPs.
Without WHE, the S-EL1 exception level is present. As you state above, there are knobs in the architecture that reduce the role of S-EL1. But based upon my current understanding, the SPMC will see S-EL1 as the next lower exception level.
If we want OPTEE to be running a number of Apps in one Secure world VM, we
wouldn't need WHE right? Can you confirm that without enabling VHE, an OPTEE VM, and its containing apps, is possible and can communicate with normal world VMs?
A S-EL0 SP can be "wrapped" as a S-EL1 SP such that the role of S-EL1 is
reduced. This could be done in SW (e.g. a shim layer in S-EL1), HW (e.g. the TGE bit above) or both. But architecturally, the SPMC will still see S-EL1.
I hope this clarifies. That said, I do need to double check the original intent and impact of TGE. So please do correct me if I have misinterpreted anything.
cheers, Achin
Thanks Raghu
-----Original Message----- From: Olivier Deprez Olivier.Deprez@arm.com Sent: Tuesday, December 15, 2020 12:18 AM To: hafnium@lists.trustedfirmware.org; raghu.ncstate@icloud.com; Olivier Deprez Olivier.Deprez@arm.com Subject: Re: [Hafnium] VHE support
Hi Raghu,
one more
5/ maybe answer to 2/3/4 is that it requires an EL1-shim embedded into Hafnium which itself ERETs to a S-EL0 partition?
BTW notice my questions are obviously oriented towards the secure implementation.
Regards, Olivier.
From: Hafnium hafnium-bounces@lists.trustedfirmware.org on behalf of Olivier Deprez via Hafnium hafnium@lists.trustedfirmware.org Sent: 15 December 2020 09:10 To: hafnium@lists.trustedfirmware.org; raghu.ncstate@icloud.com Subject: Re: [Hafnium] VHE support
Hi Raghu,
Thanks for sharing this work.
Few thoughts...
1/ I guess it requires an additional change in project/reference to eventually enable the feature for a platform (enable_vhe=1 in the gn
build
flow)?
Sorry if my questions below sound obvious, I may miss bits of the VHE architecture.
2/ The changes are effectively toggling HCR_EL2.E2H=1. Currently when Hafnium ERETs resuming a SP, this happens with the secure EL1&0
translation
regime. Though what's the next step forward? Does this require a host OS in secure world? (like linux does when
booting
under a Hypervisor with VHE enabled?) Would this be a VHE-enabled TOS?
3/ Is the later goal to enable the secure EL2&0 translation regime?
4/ Is there anything to do with HCR_EL2.TGE?
Regards, Olivier.
From: Hafnium hafnium-bounces@lists.trustedfirmware.org on behalf of
Raghu
Krishnamurthy via Hafnium hafnium@lists.trustedfirmware.org Sent: 15 December 2020 04:57 To: hafnium@lists.trustedfirmware.org Subject: [Hafnium] VHE support
Hi All,
I have a series of patches pushed to Gerrit at https://review.trustedfirmware.org/c/hafnium/hafnium/+/7599 with topic "vhe_enable". The goal of this patch series is to enable VM's in both
secure
and normal world to run with VHE enabled(hcr_el2.e2h=1), without breaking any existing functionality. This is expected to be the first step in the long term goal of enabling S-EL0 partitions(and optionally EL0
partitions),
that require VHE support, per the FF-A 1.0 Spec. I'd appreciate feedback
on
the patches and approach taken to nominally enabling VHE. Note that the
FF-A
1.0 spec(AFAIK) does not expect VHE support in the normal world but this patch series enables it anyway due to the wealth of available tests in
the
hafnium test suite to help with providing confidence in the
implementation.
The patch series has been tested as follows:
Hafnium tests using QEMU(prebuilt in the hafnium repo) - Without VHE,
since
the prebuilt QEMU does not support VHE.
Hafnium tests using QEMU(5.2-RC4, built from source) - With and without
VHE,
this version of QEMU supports VHE.
Hafnium tests using FVP 11.12.28 - With and Without VHE.
TFTF tests for secure hafnium using FVP 11.12.28 - With and without VHE.
Thanks
Raghu
-- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium -- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium
-- Hafnium mailing list Hafnium@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/hafnium