Re: [PATCH v3 0/8] Arm Live Firmware Activation (LFA) support
From: Andre Przywara
Date: Mon Jul 20 2026 - 08:51:54 EST
Hi Michal,
thanks for having a look and for testing!
On 7/14/26 13:52, Michal Suchánek wrote:
On Mon, Jul 13, 2026 at 06:02:35PM +0200, Michal Suchánek wrote:
On Mon, Jul 06, 2026 at 03:44:40PM +0200, Andre Przywara wrote:
Hi all,
this is version 3 of the Live Firmware Activation kernel support. The
device part of the code now relies on Aneesh's SMCCC bus patches[1],
which solves some problems rather nicely. I also added the formerly
missing sysfs ABI documentation. Based on v7.2-rc1, plus the first
two patches from Aneesh's series. More detailed changelog below.
==============================
This series implements the kernel side support of the Arm Live
Firmware Activation (LFA) specification [2]. LFA enables the activation
of updated firmware components without requiring a system reboot,
reducing downtime and allowing quicker deployment of critical bug fixes
in environments such as data centers and hyperscale systems.
It requires explicit firmware support, both via an agent running in EL3
(for instance in TF-A, already merged), but also in the firmware
component to be activated. TF-RMM recently merged support for this.
Unlike the usual firmware update process (which may use tools like
fwupd), LFA focuses solely on the activation of an already updated
firmware component, called "pending activation" in LFA lingo. This works
by signalling the LFA agent (part of the EL3 runtime firmware) via an
SMC call, which then does the heavy lifting of the live update, in
cooperation with the to-be-updated firmware component.
Key features of the driver:
* Detects LFA support in system firmware (EL3).
* Lists all firmware components that support live activation, identified
by their GUID.
* Exposes component attributes (e.g., activation capability, and
activation pending) via sysfs under /sys/firmware/lfa/<GUID>/.
* Provides interfaces to:
- Trigger activation of an updated firmware component.
- Cancel an ongoing activation if required.
A more detailed list of features can be found in patch 2/8.
Based on v7.2-rc1.
This work is conceptually similar to Intel’s Platform Firmware Runtime
Update and telemetry (PFRUT) [3] and TDX module updates [4], but
targets Arm platforms. The driver has been used to successfully activate
a Realm Management Monitor (RMM) firmware image in a controlled test
environment. RMM is analogous to Intel’s TDX module.
There is effort on similar work from the OCP [5]. Future work may
include integration with utilities like fwupd to automatically select
the appropriate driver, based on platform architecture, for Live/Runtime
firmware updates.
Please have a look, test and comment!
Hello,
booting a kernel with v2 of this patchset applied the module does not
get autoloaded. Loading it manually I get
[ 1972.957282] [ T5195] Arm LFA: Live Firmware Activation: detected v1.0
[ 1972.958620] [ T5195] Arm LFA: registered LFA ACPI notification
Is this expected?
I would expect the driver to load automatically.
I do not see anything in the v3 changelog obviously addressing
autoloading but changing to using a bus might affect that.
I will try to update to v3 later.
Hello,
updating to v3 of the patchset resolves the problem.
Yes, that was indeed a change that came for free with changing the probing method to be now SMCCC bus based. As Krzysztof rightfully mentioned before, the driver was always probing, then bailing out if the service was not available, which is not the way it should work under the driver model. As a side effect, there wasn't really any discovery or auto-loading mechanism. With the new SMCCC bus this should now all be solved.
Thanks for testing!
Cheers,
Andre
The driver is now autoloaded.
Thanks
Michal