FYI we are trying to get the OpenCI to use a different label (Validation-Bot-Review) which is not part our of day to day workflow for patch approvals but standard plugins being used don't seem to support non standard labels so they are working on an alternative approach. Hopefully it will be fixed soon so we don't have to manually remove the OpenCI bot setting on the CR label.
Joanna
On 18/09/2020, 09:30, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi Olivier,
Thanks for your answer.
I was not particularly worried when I saw what the error was.
And I understand it can take time to stabilize such infrastructure.
It is nice that we can have access to it now.
Regards,
Yann
-----Original Message-----
From: Olivier Deprez <Olivier.Deprez(a)arm.com>
Sent: vendredi 18 septembre 2020 10:22
To: tf-a(a)lists.trustedfirmware.org; Yann GAUTIER <yann.gautier(a)st.com>
Subject: Re: Build failure in OpenCI
Hi Yann,
The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot.
Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success).
Sorry for the trouble it causes presently.
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 18 September 2020 09:33
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Build failure in OpenCI
Hi,
I've pushed some series of patches this morning, but none of them passes the OpenCI builds and tests.
For all of them, the error is the same, Lava cannot find a file:
http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…>
See for example:
https://ci.trustedfirmware.org/job/post-build-lava/3941/console
Do you know what's wrong with this file?
And if it will be corrected soon?
Thanks,
Yann
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Yann,
The OpenCI is under enablement/works, and I think you can safely ignore those CR-1/Verified-1 from the bot.
Current CI strategy is still about maintainers applying Allow-CI+1/2 (resulting in Verified+1 on success).
Sorry for the trouble it causes presently.
Regards,
Olivier.
________________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Yann GAUTIER via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 18 September 2020 09:33
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Build failure in OpenCI
Hi,
I’ve pushed some series of patches this morning, but none of them passes the OpenCI builds and tests.
For all of them, the error is the same, Lava cannot find a file:
http://ci.trustedfirmware.org/job/tf-a-builder//ws/custom_lava_job_definiti…<http://ci.trustedfirmware.org/job/tf-a-builder/ws/custom_lava_job_definitio…>
See for example:
https://ci.trustedfirmware.org/job/post-build-lava/3941/console
Do you know what’s wrong with this file?
And if it will be corrected soon?
Thanks,
Yann
Hi Dan,
I am not sure if this is mentioned anywhere in any documents but I
think EHF handlers should be able to preempt all execution contexts at
lower ELs and lower ELs should never be able to mask such interrupts.
If the behavioral expectation is set the implementation can be fixed.
Thanks
Sandeep
On Thu, Sep 17, 2020 at 7:57 PM Dan Handley via TF-A
<tf-a(a)lists.trustedfirmware.org> wrote:
>
> A correction...
>
> > -----Original Message-----
> > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley
> > via TF-A
> > Sent: 17 September 2020 15:14
> > > >
> > > > I want to handle something similar in OP-TEED along with EHF
> > > > depending on
> > > what is the expected behavior.
> > > >
> > Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case,
> > where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-
> > EL1? Perhaps that's a better TSPD config for you to follow?
> >
> Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption.
>
Right, that is the case for yielding SMC handling where both NS
interrupts and EL3/G0 interrupts can preempt the S_EL1/S_EL2 context.
But I would expect the same routing model even for 'Fast SMC' unlike
what is happening in TSPD.
> Dan.
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
A correction...
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Dan Handley
> via TF-A
> Sent: 17 September 2020 15:14
> > >
> > > I want to handle something similar in OP-TEED along with EHF
> > > depending on
> > what is the expected behavior.
> > >
> Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case,
> where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-
> EL1? Perhaps that's a better TSPD config for you to follow?
>
Sorry, if EL3_EXCEPTION_HANDLING=1 then obviously NS interrupts are routed to EL3 first, but the TSPD re-enables NS interrupts before handing over to the TSP to handle yielding calls, via a call to ehf_allow_ns_preemption.
Dan.
Hi Sandeep
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep
> Tripathy via TF-A
> >
> > EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1
> ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
> >
> > Which means G0 interrupts (all EHF interrupts) expected to preempt any
> > execution context. And secure state cannot mask such interrupts
> >
> > eg: critical error interrupts. Sort of NMI behavior.
> >
> > However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a
> slightly different behavior. G0 interrupt cannot preempt a fast smc handler
> in SPD.
> >
> > Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’
> is in effect. Intention is to avoid NS interrupt preempt secure execution
> (Fast SMC).
> > But I think that will also disable G0 interrupt as both NS interrupt and G0
> interrupt are on FIQ.
I haven't double checked but that sounds correct.
> > EHF already ensures this by GIC PMR adjustment. So disabling routing model
> seems unnecessary in this case.
> > This is my understanding from the code please confirm if this is correct.
> >
The TSPD's TSP_NS_INTR_ASYNC_PREEMPT functionality predates the EHF, which probably explains why NS interrupts are disabled in 2 ways in this config (i.e. when both TSP_NS_INTR_ASYNC_PREEMPT and EL3_EXCEPTION_HANDLING equal 1). I guess it's possible that the call to disable the routing model can be safely removed in this config but it would require some thorough code review and testing. I'm not sure if this config is tested much at all.
> >
> >
> > Do we think it is not aligned with G0 interrupt preemption rule. Or do we
> treat Fast SMC at S_EL1/EL2 as non interruptible.
> >
I think G0 interrupts should be handled in this case but I'm not sure if this is easy to fix in the TSPD.
> >
> >
> > I want to handle something similar in OP-TEED along with EHF depending on
> what is the expected behavior.
> >
Hmm, I thought OP-TEED was more like the TSP_NS_INTR_ASYNC_PREEMPT=0 case, where NS interrupts are routed to S-EL1 while processing a yielding SMC in S-EL1? Perhaps that's a better TSPD config for you to follow?
Regards
Dan.
Updated..
On Wed, Sep 16, 2020 at 10:51 AM Sandeep Tripathy via TF-A
<tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi,
>
> EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1 ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
>
> Which means G0 interrupts (all EHF interrupts) expected to preempt any execution context. And secure state cannot mask such interrupts
>
> eg: critical error interrupts. Sort of NMI behavior.
>
>
>
> However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a slightly different behavior. G0 interrupt cannot preempt a fast smc handler in SPD.
>
> Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’ is in effect. Intention is to avoid NS interrupt preempt secure execution (Fast SMC).
> But I think that will also disable G0 interrupt as both NS interrupt and G0 interrupt are on FIQ.
> EHF already ensures this by GIC PMR adjustment. So disabling routing model seems unnecessary in this case.
> This is my understanding from the code please confirm if this is correct.
>
>
>
> Do we think it is not aligned with G0 interrupt preemption rule. Or do we treat Fast SMC at S_EL1/EL2 as non interruptible.
>
>
>
> I want to handle something similar in OP-TEED along with EHF depending on what is the expected behavior.
>
>
>
> Thanks
>
> Sandeep
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
EHF activates the routing model for ‘INTR_TYPE_EL3’ CSS = 0 , TEL3 = 1
ie FIQ trapped to EL3 and not visible and not mask-able to lower ELs.
Which means G0 interrupts (all EHF interrupts) expected to preempt any
execution context. And secure state cannot mask such interrupts
eg: critical error interrupts. Sort of NMI behavior.
However from TSPD code I see ‘TSP_NS_INTR_ASYNC_PREEMPT’ enforces a
slightly different behavior. G0 interrupt cannot preempt a fast smc handler
in SPD.
Except during yielding SMC ‘disable_intr_rm_local(INTR_TYPE_NS, SECURE);’
is in effect. Intention is to avoid NS interrupt preempt secure execution
(Fast SMC).
But I think that will also disable G0 interrupt as both NS interrupt and G0
interrupt are on FIQ.
This is my understanding from the code please confirm if this is correct.
Do we think it is not aligned with G0 interrupt preemption rule. Or do we
treat Fast SMC at S_EL1/EL2 as non interruptible.
I want to handle something similar in OP-TEED along with EHF depending on
what is the expected behavior.
Thanks
Sandeep
Hello,
ATF currently uses non-portable printf format specifiers for fixed width types defined in stdint.h
In addition, ATF redefines types defined in gcc for stdint.h with its own custom types causing additional issues.
This causes compilation issues when porting code to/from ATF.
AND, generates coverity parse errors as int64_t and uint64_t are incorrectly defined in ATF vs. gcc for aarch64.
The printf format specifiers in inttypes.h are to be used for the proper format specifiers.
And, uint64_t/int64_t should be defined the same as in gcc.
I tried fixing up all the instances of int64 printf format specifiers by introducing inttypes.h and redefined the stdint types correctly here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5437
We have checked the change into our local tree so that everything compiles and runs in our system. Please accept change upstream.
Regards,
Scott
