+Andrew Scull <ascull(a)google.com> who kindly answered this offline.
On Fri, May 22, 2020 at 9:38 AM Olivier Deprez via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> Hafnium sets CPTR_EL2.TTA (bit 28), which traps accesses to trace system
> registers to EL2.
>
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/s…
>
> However CPTR_EL2 register has a different bit field definition depending
> on HCR_EL2.E2H state.
> When HCR_EL2.E2H=0 (Hafnium case) CPTR_EL2.TTA bit position is 20.
>
> Is this a slight issue needing fix?
>
It sounds like this was copied badly from the spec and should be fixed. We
don't enable VHE and we should do as the spec says.
HTH,
Serban
>
> Regards,
> Olivier.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Hi,
Hafnium sets CPTR_EL2.TTA (bit 28), which traps accesses to trace system registers to EL2.
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/s…
However CPTR_EL2 register has a different bit field definition depending on HCR_EL2.E2H state.
When HCR_EL2.E2H=0 (Hafnium case) CPTR_EL2.TTA bit position is 20.
Is this a slight issue needing fix?
Regards,
Olivier.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
It would be useful to have a chat group of some sort for quick questions
that don't warrant an email thread. What is the preferred solution for this
for Arm and Trusted Firmware? I saw that there is already an Arm Developer
Ecosystem Discord server, would a channel there be appropriate? What does
TF-A use?
Hello,
I've run into a few issues while implementing fragmentation for memory
sharing based on the FF-A 1.0 spec, which I think need clarifying or fixing.
1. From section 13.2.2.3 points 2-6, it sounds like the 'sender' in the
case of a FFA_MEM_RETRIEVE_RESP_32 from the SPM to the non-secure
hypervisor is the SPM. Am I correct in understanding that this means that
the sender id for FFA_MEM_FRAG_TX and FFA_MEM_FRAG_RX should thus always be
the ID of the SPM, when the hypervisor is retrieving a memory region from
the SPM for the purposes of a reclaim operation from a normal world VM?
2. When a normal world VM tries to share memory with a secure partition via
FFA_MEM_SHARE, it may be that the buffer between the hypervisor and the SPM
is busy because another VM is also sharing memory or doing something else
that uses the buffer, on a different physical CPU. This could happen either
for the initial fragment sent via FFA_MEM_SHARE or for a subsequent
fragment sent with FFA_MEM_FRAG_TX. The spec currently says in section
12.3.1.2, point 13.2 that the hypervisor must return ABORTED in the
FFA_MEM_SHARE case, and doesn't allow any relevant error codes in the
description of FFA_MEM_FRAG_TX in section 13.2.2.5, though it does mention
ABORTED in section 13.2.2.3 point 8.
However, the buffer being busy need not mean that the whole transaction is
aborted; it should be possible for the sender to try again after a short
time, when hopefully the buffer is available again. So it would make more
sense for the hypervisor to return an FFA_BUSY error in this case, as it
does in other cases where a buffer is currently unavailable but the caller
can try again.
Hi Andrew,
Notice I do git clean -fdx prior to trying CHECKPATCH set/not set, because it looks there's some dependency to local ninja build files.
When CHECKPATCH is set I'm still seeing the issue mentioned earlier.
When CHECKPATCH is not set, I got failures related to missing python dependencies on my ubuntu host (ply pathlib python-git). I don't recall seeing those dependencies listed in Hafnium pages, but that's fair enough. Now the checkpatch step passes by installing those python libs.
Obviously I'm not facing this issue when running through docker hermetic build.
So I guess it's low priority glitch, not sure if it really requires a fix or a notice in documentation?
Regards,
Olivier.
________________________________________
From: Andrew Walbran
Sent: Monday, May 18, 2020 13:32
To: Olivier Deprez
Cc: hafnium(a)lists.trustedfirmware.org
Subject: Re: [Hafnium] kokoro/build and CHECKPATCH
That's weird, I haven't seen that before. Running either kokoro/build.sh or 'make checkpatch' locally works for me, whether or not CHECKPATCH is set.
The Makefile in the root directory is setting CHECKPATCH unconditionally, but it looks like the one under drive/linux uses the existing value if there is one. Maybe we should change that?
What error do you get when CHECKPATCH is not set?
On Fri, 15 May 2020 at 18:18, Olivier Deprez via Hafnium <hafnium(a)lists.trustedfirmware.org> wrote:
Hi,
Is there a known problem around checkpatch when running kokoro/build.sh locally?
I noticed if CHECKPATCH env variable is already set then kokoro/build.sh fails with:
+ export CROSS_COMPILE=aarch64-linux-gnu-
+ CROSS_COMPILE=aarch64-linux-gnu-
+ cd driver/linux
+ make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
<my-own-checkpatch-dir>/checkpatch.pl -f main.c
Must be run from the top-level dir. of a kernel tree
Makefile:43: recipe for target 'checkpatch' failed
make: *** [checkpatch] Error 2
If I unset CHECKPATCH before running build.sh then it fails at the driver/linux check.
Is this something known and/or needing fix?
Regards,
Olivier.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
That's weird, I haven't seen that before. Running either kokoro/build.sh or
'make checkpatch' locally works for me, whether or not CHECKPATCH is set.
The Makefile in the root directory is setting CHECKPATCH unconditionally,
but it looks like the one under drive/linux uses the existing value if
there is one. Maybe we should change that?
What error do you get when CHECKPATCH is not set?
On Fri, 15 May 2020 at 18:18, Olivier Deprez via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> Is there a known problem around checkpatch when running kokoro/build.sh
> locally?
>
> I noticed if CHECKPATCH env variable is already set then kokoro/build.sh
> fails with:
>
> + export CROSS_COMPILE=aarch64-linux-gnu-
> + CROSS_COMPILE=aarch64-linux-gnu-
> + cd driver/linux
> + make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
> <my-own-checkpatch-dir>/checkpatch.pl -f main.c
> Must be run from the top-level dir. of a kernel tree
> Makefile:43: recipe for target 'checkpatch' failed
> make: *** [checkpatch] Error 2
>
> If I unset CHECKPATCH before running build.sh then it fails at the
> driver/linux check.
>
> Is this something known and/or needing fix?
>
> Regards,
> Olivier.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Hi,
Is there a known problem around checkpatch when running kokoro/build.sh locally?
I noticed if CHECKPATCH env variable is already set then kokoro/build.sh fails with:
+ export CROSS_COMPILE=aarch64-linux-gnu-
+ CROSS_COMPILE=aarch64-linux-gnu-
+ cd driver/linux
+ make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
<my-own-checkpatch-dir>/checkpatch.pl -f main.c
Must be run from the top-level dir. of a kernel tree
Makefile:43: recipe for target 'checkpatch' failed
make: *** [checkpatch] Error 2
If I unset CHECKPATCH before running build.sh then it fails at the driver/linux check.
Is this something known and/or needing fix?
Regards,
Olivier.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
