Hi James & TF-A guys,
When hest acpi table configure Hardware Error Notification type as
Software Delegated Exception(0x0B) for RAS event, kernel RAS interacts with
TF-A by SDEI mechanism. On the firmware first system, kernel was notified by
TF-A sdei call.
The calling flow like as below when fatal RAS error happens:
TF-A notify kernel flow:
sdei_dispatch_event()
ehf_activate_priority()
call sdei callback // callback registered by kerenl
ehf_deactivate_priority()
Kernel sdei callback:
sdei_asm_handler()
__sdei_handler()
_sdei_handler()
sdei_event_handler()
ghes_sdei_critical_callback()
ghes_in_nmi_queue_one_entry()
/* if RAS error is fatal */
__ghes_panic()
panic()
If fatal RAS error occured, panic was called in sdei_asm_handle()
without ehf_deactivate_priority executed, which lead interrupt masked.
If interrupt masked, system would be halted in kdump flow like this:
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for cmdq
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 32768 entries for evtq
arm-smmu-v3 arm-smmu-v3.3.auto: allocated 65536 entries for priq
arm-smmu-v3 arm-smmu-v3.3.auto: SMMU currently enabled! Resetting...
So interrupt should be restored before panic otherwise kdump will hang.
In the process of sdei, a SDEI_EVENT_COMPLETE(or SDEI_EVENT_COMPLETE_AND_RESUME)
call should be called before panic for a completed run of ehf_deactivate_priority().
The ehf_deactivate_priority() function restore pmr_el1 to original value(>0x80).
The SDEI dispatch flow was broken if SDEI_EVENT_COMPLETE was not be called.
This will bring about two issue:
1 Kdump will hang for firmware reporting fatal RAS event by SDEI;
(as explain above)
2 For NMI scene,TF-A enable a secure timer, the PPI 29 will trigger periodically.
Kernel register a callback for hard lockup. The below code will not be
called when panic in kernel callback:
TF-A, services/std_svc/sdei/sdei_intr_mgmt.c sdei_intr_handler():
/*
* We reach here when client completes the event.
*
* If the cause of dispatch originally interrupted the Secure world,
* resume Secure.
*
* No need to save the Non-secure context ahead of a world switch: the
* Non-secure context was fully saved before dispatch, and has been
* returned to its pre-dispatch state.
*/
if (sec_state == SECURE)
restore_and_resume_secure_context();
/*
* The event was dispatched after receiving SDEI interrupt. With
* the event handling completed, EOI the corresponding
* interrupt.
*/
if ((map->ev_num != SDEI_EVENT_0) && !is_map_bound(map)) {
ERROR("Invalid SDEI mapping: ev=%u\n", map->ev_num);
panic();
}
plat_ic_end_of_interrupt(intr_raw);
How to fix above issues?
I think the root cause is that kernel broken the SDEI dispatch flow, so kernel
should modify to fix these issues.
Thanks,
Ming
Hi Okash,
In TF-A project, we haven't supported errata patches for system IP's like GIC-600 until now. We typically support Cat B errata patches for Arm CPU implementations that are made public.
Additionally we also support DSU errata patches for the TF-A supported CPUs as applicable.
But we are more than happy to support any code reviews required for the implementation of the below said errata.
Thanks,
Bipin
-----Original Message-----
From: tf-a-request(a)lists.trustedfirmware.org <tf-a-request(a)lists.trustedfirmware.org>
Sent: Thursday, January 27, 2022 6:00 PM
To: tf-a(a)lists.trustedfirmware.org
Subject: TF-A Digest, Vol 37, Issue 16
1. GIC-600 errata 1717652: missed wake requests (Okash Khawaja)
----------------------------------------------------------------------
Message: 1
Date: Thu, 27 Jan 2022 13:36:32 +0000
From: Okash Khawaja <okash(a)google.com>
Subject: [TF-A] GIC-600 errata 1717652: missed wake requests
To: tf-a(a)lists.trustedfirmware.org
Message-ID:
<CAGjWKv6TTLVvF7GfsmY76QFjSzcSX8DqPuPukJQAOH-AqAvuLg(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
It seems like TF-A's GIC600 driver currently doesn't have support for the Cat B errata 1717652 "Wake_request may not be delivered if multiple cores are woken by PPIs at the same time". Are there plans to support this?
Thanks,
Okash
------------------------------
Subject: Digest Footer
TF-A mailing list -- tf-a(a)lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org
------------------------------
End of TF-A Digest, Vol 37, Issue 16
************************************
Hi,
It seems like TF-A's GIC600 driver currently doesn't have support for
the Cat B errata 1717652 "Wake_request may not be delivered if
multiple cores are woken by PPIs at the same time". Are there plans to
support this?
Thanks,
Okash
This event has been changed.
Title: TF-A Tech Forum
Agenda for Session on 27th January 2020Introduction of Arm CCA Context
ManagementSession Presented by: Manish Pandey, Soby Mathew and Zelalem
AwekeDetails: With the introduction of Arm CCA, the context management
library needs to manage the context for one more world (realm world). Since
the current context management library has evolved over time, some of
design principles need sharpening / re-defining to make it easier to manage
and make it less error-prone when managing the 3 worlds. The proposal lists
down the design principles and discusses about introduction of new CPU
Context for the root world (EL3). The refactor will increase the overall
robustness of EL3 firmware as it will enforce a design pattern in software
plus have a more predictable sysreg state during execution at EL3.We run an
open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h (changed)
When: Thu Jan 27, 2022 4pm – 5pm United Kingdom Time
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
* Bill Fletcher - creator
* marek.bykowski(a)gmail.com
* okash.khawaja(a)gmail.com
* tf-a(a)lists.trustedfirmware.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Agenda for Session on 27th January 2020
* Introduction of Arm CCA Context Management
* Session Presented by: Manish Pandey, Soby Mathew and Zelalem Aweke
* Details: With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.
We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.
Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/<https://www.google.com/url?q=https://www.trustedfirmware.org/meetings/tf-a-…>
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/9159704974<https://www.google.com/url?q=https://zoom.us/j/9159704974&sa=D&source=calen…>
Meeting ID: 915 970 4974
One tap mobile
+16465588656,,9159704974# US (New York)
+16699009128,,9159704974# US (San Jose)
Dial by your location
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
877 853 5247 US Toll-free
888 788 0099 US Toll-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https://zoom.us/u/ad27hc6t7h&sa=D&source=calen…>
This event has been changed.
Title: TF-A Tech Forum
Agenda for Session on 27th January 2020introduction of Arm CCA Context
ManagementSession Presented by: Manish Pandy, Soby Mathew and Zelalem
AwekeDetails: With the introduction of Arm CCA, the context management
library needs to manage the context for one more world (realm world). Since
the current context management library has evolved over time, some of
design principles need sharpening / re-defining to make it easier to manage
and make it less error-prone when managing the 3 worlds. The proposal lists
down the design principles and discusses about introduction of new CPU
Context for the root world (EL3). The refactor will increase the overall
robustness of EL3 firmware as it will enforce a design pattern in software
plus have a more predictable sysreg state during execution at EL3.We run an
open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h (changed)
When: Thu Jan 27, 2022 4pm – 5pm United Kingdom Time
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
* Bill Fletcher - creator
* marek.bykowski(a)gmail.com
* okash.khawaja(a)gmail.com
* tf-a(a)lists.trustedfirmware.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hello Everyone,
We have a proposal to refactor the Context management framework in TF-A and an RFC is pushed for review here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/13651 . The abstract of the RFC is given below:
With the introduction of Arm CCA, the context management library needs to manage the context for one more world (realm world). Since the current context management library has evolved over time, some of design principles need sharpening / re-defining to make it easier to manage and make it less error-prone when managing the 3 worlds. The proposal lists down the design principles and discusses about introduction of new CPU Context for the root world (EL3). The refactor will increase the overall robustness of EL3 firmware as it will enforce a design pattern in software plus have a more predictable sysreg state during execution at EL3.
The plus point here is that many of the design principles are already adhered to in one way or other in the current the implementation so much of the work can be done in an incremental fashion without much disruption. Along with @Zelalem Aweke<mailto:Zelalem.Aweke@arm.com> and @Manish Pandey2<mailto:Manish.Pandey2@arm.com>, we hope to discuss the this RFC and how this translates to code changes in TF-A during the Tech Forum this week.
Best Regards
Soby Mathew
Hi,
arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE
and ARM_NS_DRAM2_BASE only, for some platform there are include more than two
non-secure dram areas.
It will bring dependencies between TF-A and physical memory space which can get
from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the
entire physical memory space.
In my mind, the kernel should guarantee the validity of entry point.
So why this check is need?
Thanks,
Ming
Hi,
I am running U-Boot 2022.01 on imx8mm-evk. If I build the NXP
vendor-based TF-A (imx_5.4.47_2.2.0) I am able to boot kernel 5.16
just fine.
However, if I use the upstream TF-A (v2.5 or v2.6), the kernel fails
to boot most of the attempts.
Peng, Jacky,
Could you please try booting kernel 5.16 + U-Boot 2022.01 built with TF-A v2.6?
What is missing in upstream TF-A to be able to boot kernel 5.16?
Thanks,
Fabio Estevam
Dear all,
(and may the new year be happy to you and your beloved)
In the course of evaluating the FW update flows for systems with FIP images, we identified the following requirements:
Req1:
The FIP image, or the components in the FIP, must have a version field. Each version field will be compared against the anti-rollback counter of the platform that the FIP or its component is bound to.
Req2:
We must be able to increment the FIP version field (though a FIP image FW update) without affecting the anti-rollback counter value. The anti-rollback counter should be incremented only for security updates upon explicit request.
Req3:
The version field should be present even if the FIP does not contain image certificates.
Currently the FIP carries a version field in the different certificates, the anti-rollback counters are updated every time the root certificate value increased. This is not flexible enough and does not allow trial/acceptance of updates.
Can we open a discussion on how to enhance the version/anti-rollback counter update in TF-A?
Best regards,
Etienne Carriere
ST Restricted