* Re: [PATCH v1 2/3] virt: tsm: Increase TSM_REPORT_OUTBLOB_MAX to 16MB
From: dan.j.williams @ 2026-02-11 2:16 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan, Dan Williams, Kirill A . Shutemov
Cc: Dave Hansen, Rick Edgecombe, x86, linux-kernel, linux-coco
In-Reply-To: <20260211001712.1531955-3-sathyanarayanan.kuppuswamy@linux.intel.com>
Kuppuswamy Sathyanarayanan wrote:
> Confidential Computing (CoCo) attestation is evolving toward
> standardized models such as DICE (Device Identifier Composition Engine)
> and Post-Quantum Cryptography (PQC), which rely on layered certificate
> chains and larger cryptographic signatures.
>
> A typical PQC certificate can range from 5KB to 15KB, and DICE-based
> architectures accumulate these certificates across multiple boot
> stages. In such configurations, the total attestation evidence can
> reach several megabytes, exceeding the current 32KB limit.
>
> Increase TSM_REPORT_OUTBLOB_MAX to 16MB to accommodate these larger
> certificate chains. This provides sufficient headroom to handle
> evolving requirements without requiring frequent updates to the limit.
>
> TSM_REPORT_OUTBLOB_MAX is used by the configfs read interface to cap
> the maximum allowed binary blob size for outblob, auxblob and
> manifestblob attributes. Hence, the per-open-file worst case memory
> allocation increases from 32KB to 16MB. Multiple concurrent readers
> multiply this cost (e.g., N readers of an M-byte blob incur NxM bytes
> of vmalloc-backed memory). However, allocations are performed on demand
> and remain proportional to the actual blob length, not the configured
> maximum.
Looks ok, again I will change the subject to:
"configfs-tsm-report: Increase TSM_REPORT_OUTBLOB_MAX to 16MB"
^ permalink raw reply
* Re: [PATCH v1 1/3] virt: tsm: Document size limits for outblob attributes
From: dan.j.williams @ 2026-02-11 2:15 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan, Dan Williams, Kirill A . Shutemov
Cc: Dave Hansen, Rick Edgecombe, x86, linux-kernel, linux-coco
In-Reply-To: <20260211001712.1531955-2-sathyanarayanan.kuppuswamy@linux.intel.com>
Kuppuswamy Sathyanarayanan wrote:
> The configfs-tsm-report interface can fail with -EFBIG when the
> attestation report generated by a TSM provider exceeds internal
> maximums (TSM_REPORT_OUTBLOB_MAX). However, this error condition and
> its handling are not currently documented in the ABI.
>
> Userspace tools need to understand how to interpret various error
> conditions when reading attestation reports.
>
> Document that reads fail with -EFBIG when reports exceed size limits,
> with guidance on how to resolve them.
>
> Reviewed-by: Fang Peter <peter.fang@intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Looks good, I will change the subject to:
"configfs-tsm-report: Document size limits for outblob attributes"
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Edgecombe, Rick P @ 2026-02-11 0:50 UTC (permalink / raw)
To: Hansen, Dave, seanjc@google.com, x86@kernel.org,
dave.hansen@linux.intel.com, kas@kernel.org, bp@alien8.de,
mingo@redhat.com, tglx@kernel.org, pbonzini@redhat.com
Cc: Huang, Kai, ackerleytng@google.com, sagis@google.com,
Annapurve, Vishal, linux-kernel@vger.kernel.org, Zhao, Yan Y,
Li, Xiaoyao, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
Yamahata, Isaku, binbin.wu@linux.intel.com
In-Reply-To: <655724f8-0098-40ee-a097-ce4c0249933d@intel.com>
On Tue, 2026-02-10 at 09:44 -0800, Dave Hansen wrote:
> slow_path = atomic_dec_and_lock(fine-grained-refcount,
> pamt_lock)
> if (!slow_path)
> goto out;
I guess if it returns 0, the lock is not held. So we can just return.
>
> // fine-grained-refcount==0 and must stay that way with
> // pamt_lock held. Remove the DPAMT pages:
> tdh_phymem_pamt_remove(page, pamt_pa_array)
> out:
> spin_unlock(pamt_lock)
>
> On the acquire side, you do:
>
> fast_path = atomic_inc_not_zero(fine-grained-refcount)
> if (fast_path)
> return;
>
> // slow path:
> spin_lock(pamt_lock)
>
> // Was the race lost with another 0=>1 increment?
> if (atomic_read(fine-grained-refcount) > 0)
> goto out_inc
>
> tdh_phymem_pamt_add(page, pamt_pa_array)
> // Inc after the TDCALL so another thread won't race ahead of us
> // and try to use a non-existent PAMT entry
> out_inc:
> atomic_inc(fine-grained-refcount)
> spin_unlock(pamt_lock)
>
> Then, at least only the 0=>1 and 1=>0 transitions need the global lock.
> The fast paths only touch the refcount which isn't shared nearly as much
> as the global lock.
>
> BTW, this probably still needs to be spin_lock_irq(), not what I wrote
> above, but that's not a big deal to add.
>
> I've stared at this for a bit and don't see any holes. Does anyone else
> see any?
I don't see any issues. It is largely similar to the version in the next patch
except we don't need to handle the HPA_RANGE_NOT_FREE case specially. It does
this without taking the lock in any more cases. So seems like a nice code
reduction.
It probably is still worth keeping the comment about the get/put race somewhere.
I'll see if I can slot it in somewhere.
^ permalink raw reply
* [PATCH v1 3/3] virt: tdx-guest: Increase Quote buffer size to 128KB
From: Kuppuswamy Sathyanarayanan @ 2026-02-11 0:17 UTC (permalink / raw)
To: Dan Williams, Kirill A . Shutemov
Cc: Dave Hansen, Rick Edgecombe, x86, linux-kernel, linux-coco
In-Reply-To: <20260211001712.1531955-1-sathyanarayanan.kuppuswamy@linux.intel.com>
Intel platforms are transitioning from traditional SGX-based
attestation toward DICE-based attestation as part of a broader move
toward open and standardized attestation models. DICE enables layered
and extensible attestation, where evidence is accumulated across
multiple boot stages.
With SGX-based attestation, Quote sizes are typically under 8KB, as the
payload consists primarily of Quote data and a small certificate bundle.
Existing TDX guest code sizes the Quote buffer accordingly.
DICE-based attestation produces significantly larger Quotes due to the
inclusion of evidence (certificate chains) from multiple boot layers.
The cumulative Quote size can reach approximately 100KB.
Increase GET_QUOTE_BUF_SIZE to 128KB to ensure sufficient buffer
capacity for DICE-based Quote payloads.
Reviewed-by: Fang Peter <peter.fang@intel.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
Documentation/ABI/testing/configfs-tsm-report | 4 ++++
drivers/virt/coco/tdx-guest/tdx-guest.c | 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/configfs-tsm-report b/Documentation/ABI/testing/configfs-tsm-report
index ca3352cfd2f1..7a6a5045a7d5 100644
--- a/Documentation/ABI/testing/configfs-tsm-report
+++ b/Documentation/ABI/testing/configfs-tsm-report
@@ -73,6 +73,10 @@ Description:
Library Revision 0.8 Appendix 4,5
https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
+ Intel TDX platforms with DICE-based attestation use CBOR Web Token
+ (CWT) format for the Quote payload. This is indicated by the Quote
+ size exceeding 8KB.
+
What: /sys/kernel/config/tsm/report/$name/generation
Date: September, 2023
KernelVersion: v6.7
diff --git a/drivers/virt/coco/tdx-guest/tdx-guest.c b/drivers/virt/coco/tdx-guest/tdx-guest.c
index 4e239ec960c9..4252b147593a 100644
--- a/drivers/virt/coco/tdx-guest/tdx-guest.c
+++ b/drivers/virt/coco/tdx-guest/tdx-guest.c
@@ -160,8 +160,10 @@ static void tdx_mr_deinit(const struct attribute_group *mr_grp)
/*
* Intel's SGX QE implementation generally uses Quote size less
* than 8K (2K Quote data + ~5K of certificate blob).
+ * DICE-based attestation uses layered evidence that requires
+ * larger Quote size (~100K).
*/
-#define GET_QUOTE_BUF_SIZE SZ_8K
+#define GET_QUOTE_BUF_SIZE SZ_128K
#define GET_QUOTE_CMD_VER 1
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/3] virt: tsm: Increase TSM_REPORT_OUTBLOB_MAX to 16MB
From: Kuppuswamy Sathyanarayanan @ 2026-02-11 0:17 UTC (permalink / raw)
To: Dan Williams, Kirill A . Shutemov
Cc: Dave Hansen, Rick Edgecombe, x86, linux-kernel, linux-coco
In-Reply-To: <20260211001712.1531955-1-sathyanarayanan.kuppuswamy@linux.intel.com>
Confidential Computing (CoCo) attestation is evolving toward
standardized models such as DICE (Device Identifier Composition Engine)
and Post-Quantum Cryptography (PQC), which rely on layered certificate
chains and larger cryptographic signatures.
A typical PQC certificate can range from 5KB to 15KB, and DICE-based
architectures accumulate these certificates across multiple boot
stages. In such configurations, the total attestation evidence can
reach several megabytes, exceeding the current 32KB limit.
Increase TSM_REPORT_OUTBLOB_MAX to 16MB to accommodate these larger
certificate chains. This provides sufficient headroom to handle
evolving requirements without requiring frequent updates to the limit.
TSM_REPORT_OUTBLOB_MAX is used by the configfs read interface to cap
the maximum allowed binary blob size for outblob, auxblob and
manifestblob attributes. Hence, the per-open-file worst case memory
allocation increases from 32KB to 16MB. Multiple concurrent readers
multiply this cost (e.g., N readers of an M-byte blob incur NxM bytes
of vmalloc-backed memory). However, allocations are performed on demand
and remain proportional to the actual blob length, not the configured
maximum.
Reviewed-by: Fang Peter <peter.fang@intel.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
include/linux/tsm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/tsm.h b/include/linux/tsm.h
index a3b7ab668eff..7f72a154b6b2 100644
--- a/include/linux/tsm.h
+++ b/include/linux/tsm.h
@@ -8,7 +8,7 @@
#include <linux/device.h>
#define TSM_REPORT_INBLOB_MAX 64
-#define TSM_REPORT_OUTBLOB_MAX SZ_32K
+#define TSM_REPORT_OUTBLOB_MAX SZ_16M
/*
* Privilege level is a nested permission concept to allow confidential
--
2.43.0
^ permalink raw reply related
* [PATCH v1 1/3] virt: tsm: Document size limits for outblob attributes
From: Kuppuswamy Sathyanarayanan @ 2026-02-11 0:17 UTC (permalink / raw)
To: Dan Williams, Kirill A . Shutemov
Cc: Dave Hansen, Rick Edgecombe, x86, linux-kernel, linux-coco
In-Reply-To: <20260211001712.1531955-1-sathyanarayanan.kuppuswamy@linux.intel.com>
The configfs-tsm-report interface can fail with -EFBIG when the
attestation report generated by a TSM provider exceeds internal
maximums (TSM_REPORT_OUTBLOB_MAX). However, this error condition and
its handling are not currently documented in the ABI.
Userspace tools need to understand how to interpret various error
conditions when reading attestation reports.
Document that reads fail with -EFBIG when reports exceed size limits,
with guidance on how to resolve them.
Reviewed-by: Fang Peter <peter.fang@intel.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
---
Documentation/ABI/testing/configfs-tsm-report | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/ABI/testing/configfs-tsm-report b/Documentation/ABI/testing/configfs-tsm-report
index 534408bc1408..ca3352cfd2f1 100644
--- a/Documentation/ABI/testing/configfs-tsm-report
+++ b/Documentation/ABI/testing/configfs-tsm-report
@@ -17,6 +17,12 @@ Description:
where the implementation is conveyed via the @provider
attribute.
+ This interface fails reads and sets errno to EFBIG when the
+ report generated by @provider exceeds the configfs-tsm-report
+ internal maximums. Contact the platform provider for the
+ compatible security module, driver, and attestation library
+ combination.
+
What: /sys/kernel/config/tsm/report/$name/auxblob
Date: October, 2023
KernelVersion: v6.7
@@ -31,6 +37,9 @@ Description:
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
+ See "EFBIG" comment in the @outblob description for potential
+ error conditions.
+
What: /sys/kernel/config/tsm/report/$name/manifestblob
Date: January, 2024
KernelVersion: v6.10
@@ -43,6 +52,9 @@ Description:
See 'service_provider' for information on the format of the
manifest blob.
+ See "EFBIG" comment in the @outblob description for potential
+ error conditions.
+
What: /sys/kernel/config/tsm/report/$name/provider
Date: September, 2023
KernelVersion: v6.7
--
2.43.0
^ permalink raw reply related
* [PATCH v1 0/3] Increase CoCo attestation report buffer size
From: Kuppuswamy Sathyanarayanan @ 2026-02-11 0:17 UTC (permalink / raw)
To: Dan Williams, Kirill A . Shutemov
Cc: Dave Hansen, Rick Edgecombe, x86, linux-kernel, linux-coco
Hi All,
This patch series addresses buffer size limitations in the Confidential
Computing (CoCo) attestation stack. These changes are necessary to
support emerging security requirements such as DICE-based attestation
and Post-Quantum Cryptography (PQC).
DICE relies on layered evidence collected across multiple boot stages,
where each stage contributes to a cumulative certificate chain. This
process can increase the total report size to over 100KB. Furthermore,
with PQC support enabled, evidence size can reach several MB due to
larger cryptographic signatures and certificates.
Current Intel platforms use SGX-based attestation with Quote sizes
typically under 8KB. Newer Intel platforms will support DICE-based
attestation, requiring larger buffers.
This series extends the TSM framework to support reports up to 16MB,
providing sufficient headroom for these security standards. It also
increases the TDX Quote buffer size to 128KB to accommodate DICE-based
attestation.
Patch Details:
Patch 1/3 - Documents TSM binary blob size limits.
Patch 2/3 - Increases the generic TSM maximum output blob size from
32KB to 16MB.
Patch 3/3 - Increases the TDX-specific GET_QUOTE_BUF_SIZE from 8KB to
128KB to support DICE-based attestation.
Kuppuswamy Sathyanarayanan (3):
virt: tsm: Document size limits for outblob attributes
virt: tsm: Increase TSM_REPORT_OUTBLOB_MAX to 16MB
virt: tdx-guest: Increase Quote buffer size to 128KB
Documentation/ABI/testing/configfs-tsm-report | 16 ++++++++++++++++
drivers/virt/coco/tdx-guest/tdx-guest.c | 4 +++-
include/linux/tsm.h | 2 +-
3 files changed, 20 insertions(+), 2 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/2] firmware: smccc: add timeout, touch wdt
From: Vedashree Vidwans @ 2026-02-10 23:46 UTC (permalink / raw)
To: Trilok Soni, salman.nabi, sudeep.holla, andre.przywara,
lpieralisi, mark.rutland
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar
In-Reply-To: <cb7f90b5-6e13-4659-a448-1f621b89c71a@oss.qualcomm.com>
On 2/10/26 15:10, Trilok Soni wrote:
> On 2/10/2026 2:40 PM, Vedashree Vidwans wrote:
>> Enhance PRIME/ACTIVATION functions to touch watchdog and implement
>> timeout mechanism. This update ensures that any potential hangs are
>> detected promptly and that the LFA process is allocated sufficient
>> execution time before the watchdog timer expires. These changes improve
>> overall system reliability by reducing the risk of undetected process
>> stalls and unexpected watchdog resets.
>>
>> Signed-off-by: Vedashree Vidwans <vvidwans@nvidia.com>
>> ---
>> drivers/firmware/smccc/lfa_fw.c | 40 +++++++++++++++++++++++++++++++++
>> 1 file changed, 40 insertions(+)
>>
>> diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
>> index da6b54fe1685..b0ace6fc8dac 100644
>> --- a/drivers/firmware/smccc/lfa_fw.c
>> +++ b/drivers/firmware/smccc/lfa_fw.c
>> @@ -17,6 +17,9 @@
>> #include <linux/array_size.h>
>> #include <linux/list.h>
>> #include <linux/mutex.h>
>> +#include <linux/nmi.h>
>> +#include <linux/ktime.h>
>> +#include <linux/delay.h>
>>
>> #undef pr_fmt
>> #define pr_fmt(fmt) "Arm LFA: " fmt
>> @@ -37,6 +40,14 @@
>> #define LFA_PRIME_CALL_AGAIN BIT(0)
>> #define LFA_ACTIVATE_CALL_AGAIN BIT(0)
>>
>> +/* Prime loop limits, TODO: tune after testing */
>
> Do you want to keep this TODO? Your patches are not marked as RFC.
>
>> +#define LFA_PRIME_BUDGET_US 30000000 /* 30s cap */
>> +#define LFA_PRIME_POLL_DELAY_US 10 /* 10us between polls */
>
> Are these values going to be tunable from the userspace or kernel module parameters?
>
>> +
>> +/* Activation loop limits, TODO: tune after testing */
>
> Ditto.
>
>> +#define LFA_ACTIVATE_BUDGET_US 20000000 /* 20s cap */
>> +#define LFA_ACTIVATE_POLL_DELAY_US 10 /* 10us between polls */
> ...
>
> ---Trilok Soni
Thanks for pointing this out.
The "TODO: tune after testing" comment was left in by mistake; it should
not have been included in a non‑RFC posting.
Regarding tunability: the current series uses fixed values, but I agree
it would be useful to make these configurable. Adding module parameter
to adjust the timeout values would make it easier to tune them for
different platforms and workloads.
I’ll address both of these points in the next revision of the series.
Veda
^ permalink raw reply
* Re: [PATCH 1/2] firmware: smccc: add timeout, touch wdt
From: Trilok Soni @ 2026-02-10 23:10 UTC (permalink / raw)
To: Vedashree Vidwans, salman.nabi, sudeep.holla, andre.przywara,
lpieralisi, mark.rutland
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar
In-Reply-To: <20260210224023.2341728-2-vvidwans@nvidia.com>
On 2/10/2026 2:40 PM, Vedashree Vidwans wrote:
> Enhance PRIME/ACTIVATION functions to touch watchdog and implement
> timeout mechanism. This update ensures that any potential hangs are
> detected promptly and that the LFA process is allocated sufficient
> execution time before the watchdog timer expires. These changes improve
> overall system reliability by reducing the risk of undetected process
> stalls and unexpected watchdog resets.
>
> Signed-off-by: Vedashree Vidwans <vvidwans@nvidia.com>
> ---
> drivers/firmware/smccc/lfa_fw.c | 40 +++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
>
> diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
> index da6b54fe1685..b0ace6fc8dac 100644
> --- a/drivers/firmware/smccc/lfa_fw.c
> +++ b/drivers/firmware/smccc/lfa_fw.c
> @@ -17,6 +17,9 @@
> #include <linux/array_size.h>
> #include <linux/list.h>
> #include <linux/mutex.h>
> +#include <linux/nmi.h>
> +#include <linux/ktime.h>
> +#include <linux/delay.h>
>
> #undef pr_fmt
> #define pr_fmt(fmt) "Arm LFA: " fmt
> @@ -37,6 +40,14 @@
> #define LFA_PRIME_CALL_AGAIN BIT(0)
> #define LFA_ACTIVATE_CALL_AGAIN BIT(0)
>
> +/* Prime loop limits, TODO: tune after testing */
Do you want to keep this TODO? Your patches are not marked as RFC.
> +#define LFA_PRIME_BUDGET_US 30000000 /* 30s cap */
> +#define LFA_PRIME_POLL_DELAY_US 10 /* 10us between polls */
Are these values going to be tunable from the userspace or kernel module parameters?
> +
> +/* Activation loop limits, TODO: tune after testing */
Ditto.
> +#define LFA_ACTIVATE_BUDGET_US 20000000 /* 20s cap */
> +#define LFA_ACTIVATE_POLL_DELAY_US 10 /* 10us between polls */
...
---Trilok Soni
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Huang, Kai @ 2026-02-10 23:02 UTC (permalink / raw)
To: Hansen, Dave, seanjc@google.com, x86@kernel.org, kas@kernel.org,
dave.hansen@linux.intel.com, mingo@redhat.com, bp@alien8.de,
tglx@kernel.org, Edgecombe, Rick P, pbonzini@redhat.com
Cc: ackerleytng@google.com, sagis@google.com, Li, Xiaoyao,
linux-kernel@vger.kernel.org, Zhao, Yan Y, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, Yamahata, Isaku,
binbin.wu@linux.intel.com, Annapurve, Vishal
In-Reply-To: <17d3ba24-7d58-4507-a5d7-43237974ba09@intel.com>
On Tue, 2026-02-10 at 14:50 -0800, Dave Hansen wrote:
> On 2/10/26 14:46, Huang, Kai wrote:
> > Sorry I am a bit confused. But I think the "1=>0 and lock" are atomic
> > together?
>
> Maybe I'm being pedantic. The 1=>0 happens under the lock, but the 1=>0
> and the lock acquisition itself are not atomic. You can see them
> happening at different times:
Oh I see. Thanks.
>
> int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
> {
> /* Subtract 1 from counter unless that drops it to 0...
> if (atomic_add_unless(atomic, -1, 1))
> return 0;
>
> /* Otherwise do it the slow way */
> spin_lock(lock);
> if (atomic_dec_and_test(atomic))
> return 1;
> spin_unlock(lock);
> return 0;
> }
>
> tl;dr: Kirill was right, atomic_dec_and_test() doesn't work by itself here.
>
> But I think atomic_dec_and_lock() will.
Agreed.
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Dave Hansen @ 2026-02-10 22:50 UTC (permalink / raw)
To: Huang, Kai, seanjc@google.com, bp@alien8.de, kas@kernel.org,
dave.hansen@linux.intel.com, mingo@redhat.com, x86@kernel.org,
tglx@kernel.org, Edgecombe, Rick P, pbonzini@redhat.com
Cc: ackerleytng@google.com, sagis@google.com, Li, Xiaoyao,
linux-kernel@vger.kernel.org, Zhao, Yan Y, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, Yamahata, Isaku,
binbin.wu@linux.intel.com, Annapurve, Vishal
In-Reply-To: <b9b4b80a3818e9ebb3cb1aec76d1a1083fb91c7c.camel@intel.com>
On 2/10/26 14:46, Huang, Kai wrote:
> Sorry I am a bit confused. But I think the "1=>0 and lock" are atomic
> together?
Maybe I'm being pedantic. The 1=>0 happens under the lock, but the 1=>0
and the lock acquisition itself are not atomic. You can see them
happening at different times:
int _atomic_dec_and_lock(atomic_t *atomic, spinlock_t *lock)
{
/* Subtract 1 from counter unless that drops it to 0...
if (atomic_add_unless(atomic, -1, 1))
return 0;
/* Otherwise do it the slow way */
spin_lock(lock);
if (atomic_dec_and_test(atomic))
return 1;
spin_unlock(lock);
return 0;
}
tl;dr: Kirill was right, atomic_dec_and_test() doesn't work by itself here.
But I think atomic_dec_and_lock() will.
Does anyone disagree?
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Huang, Kai @ 2026-02-10 22:46 UTC (permalink / raw)
To: Hansen, Dave, seanjc@google.com, bp@alien8.de, kas@kernel.org,
dave.hansen@linux.intel.com, mingo@redhat.com, x86@kernel.org,
tglx@kernel.org, Edgecombe, Rick P, pbonzini@redhat.com
Cc: ackerleytng@google.com, sagis@google.com, Li, Xiaoyao,
linux-kernel@vger.kernel.org, Zhao, Yan Y, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, Yamahata, Isaku,
binbin.wu@linux.intel.com, Annapurve, Vishal
In-Reply-To: <4fe6121b-6fe3-4c97-b796-806533ed6806@intel.com>
On Tue, 2026-02-10 at 14:19 -0800, Dave Hansen wrote:
> On 2/10/26 14:15, Edgecombe, Rick P wrote:
> > I'm wasn't familiar with atomic_dec_and_lock(). I'm guess the atomic
> > part doesn't cover both decrementing *and* taking the lock?
>
> Right. Only 1=>0 is under the lock. All other decs are outside the lock.
>
> It doesn't do the atomic and the lock "atomically together" somehow.
Sorry I am a bit confused. But I think the "1=>0 and lock" are atomic
together?
If so, I think we can avoid the "race" mentioned by Rick, which is handled
by "x86/virt/tdx: Optimize tdx_alloc/free_control_page() helpers".
Kirill described the race [*]. Quote it here:
---
Consider the following scenario
CPU0 CPU1
tdx_pamt_put()
atomic_dec_and_test() == true
tdx_pamt_get()
atomic_inc_not_zero() == false
tdx_pamt_add()
<takes pamt_lock>
// CPU0 never removed PAMTmemory
tdh_phymem_pamt_add() ==
HPA_RANGE_NOT_FREE
atomic_set(1);
<drops pamt_lock>
<takes pamt_lock>
// Lost the race to CPU1
atomic_read() > 0
<drop pamt_lock>
---
But with atomic_dec_and_lock() (assuming "1=>0 and lock" is atomic), I think
this race won't happen. In tdx_pamt_put() on CPU0, the lock will always be
grabbed when refcount becomes 0, so PAMT pages are guaranteed to be freed.
Therefore tdx_pamt_get() on CPU1 should never meet "HPA_RANGE_NOT_FREE".
[*]
https://lore.kernel.org/kvm/bfaswqmlsyycr3alibn6f422cjtpd6ybssjekvrrz4zdwgwfcz@pxy25ra4sln2/
^ permalink raw reply
* [PATCH 2/2] firmware: smccc: register as platform driver
From: Vedashree Vidwans @ 2026-02-10 22:40 UTC (permalink / raw)
To: salman.nabi, sudeep.holla, andre.przywara, lpieralisi,
mark.rutland, trilokkumar.soni
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar, Vedashree Vidwans
In-Reply-To: <20260210224023.2341728-1-vvidwans@nvidia.com>
- Register the LFA driver as a platform driver corresponding to
'arml0003' ACPI device. The driver will be invoked when the device is
detected on a platform. NOTE: current functionality only available for
ACPI configuration.
- Add functionality to register ACPI notify handler for LFA in the
driver probe().
- When notify handler is invoked, driver will query latest FW component
details and trigger activation of capable and pending FW component in a
loop until all FWs are activated.
ACPI node snippet from LFA spec[1]:
Device (LFA0) {
Name (_HID, "ARML0003")
Name (_UID, 0)
}
[1] https://developer.arm.com/documentation/den0147/latest/
Signed-off-by: Vedashree Vidwans <vvidwans@nvidia.com>
---
drivers/firmware/smccc/lfa_fw.c | 153 ++++++++++++++++++++++++++++----
1 file changed, 134 insertions(+), 19 deletions(-)
diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
index b0ace6fc8dac..042de937bf83 100644
--- a/drivers/firmware/smccc/lfa_fw.c
+++ b/drivers/firmware/smccc/lfa_fw.c
@@ -20,7 +20,10 @@
#include <linux/nmi.h>
#include <linux/ktime.h>
#include <linux/delay.h>
+#include <linux/acpi.h>
+#include <linux/platform_device.h>
+#define DRIVER_NAME "ARM_LFA"
#undef pr_fmt
#define pr_fmt(fmt) "Arm LFA: " fmt
@@ -284,26 +287,7 @@ static int activate_fw_image(struct image_props *attrs)
return lfa_cancel(attrs);
}
- /*
- * Invalidate fw_seq_ids (-1) for all images as the seq_ids and the
- * number of firmware images in the LFA agent may change after a
- * successful activation attempt. Negate all image flags as well.
- */
- attrs = NULL;
- list_for_each_entry(attrs, &lfa_fw_images, image_node) {
- set_image_flags(attrs, -1, 0b1000, 0, 0);
- }
-
update_fw_images_tree();
-
- /*
- * Removing non-valid image directories at the end of an activation.
- * We can't remove the sysfs attributes while in the respective
- * _store() handler, so have to postpone the list removal to a
- * workqueue.
- */
- INIT_WORK(&fw_images_update_work, remove_invalid_fw_images);
- queue_work(fw_images_update_wq, &fw_images_update_work);
mutex_unlock(&lfa_lock);
return ret;
@@ -627,6 +611,7 @@ static int update_fw_images_tree(void)
{
struct arm_smccc_1_2_regs reg = { 0 };
struct uuid_regs image_uuid;
+ struct image_props *attrs;
char image_id_str[40];
int ret, num_of_components;
@@ -636,6 +621,15 @@ static int update_fw_images_tree(void)
return -ENODEV;
}
+ /*
+ * Invalidate fw_seq_ids (-1) for all images as the seq_ids and the
+ * number of firmware images in the LFA agent may change after a
+ * successful activation attempt. Negate all image flags as well.
+ */
+ list_for_each_entry(attrs, &lfa_fw_images, image_node) {
+ set_image_flags(attrs, -1, 0b1000, 0, 0);
+ }
+
for (int i = 0; i < num_of_components; i++) {
reg.a0 = LFA_1_0_FN_GET_INVENTORY;
reg.a1 = i; /* fw_seq_id under consideration */
@@ -653,9 +647,121 @@ static int update_fw_images_tree(void)
}
}
+ /*
+ * Removing non-valid image directories at the end of an activation.
+ * We can't remove the sysfs attributes while in the respective
+ * _store() handler, so have to postpone the list removal to a
+ * workqueue.
+ */
+ INIT_WORK(&fw_images_update_work, remove_invalid_fw_images);
+ queue_work(fw_images_update_wq, &fw_images_update_work);
+
+ return 0;
+}
+
+#if defined(CONFIG_ACPI)
+static void lfa_notify_handler(acpi_handle handle, u32 event, void *data)
+{
+ struct image_props *attrs = NULL;
+ int ret;
+ bool found_activable_image = false;
+
+ /* Get latest FW inventory */
+ mutex_lock(&lfa_lock);
+ ret = update_fw_images_tree();
+ mutex_unlock(&lfa_lock);
+ if (ret != 0) {
+ pr_err("FW images tree update failed");
+ return;
+ }
+
+ /*
+ * Go through all FW images in a loop and trigger activation
+ * of all activable and pending images.
+ */
+ do {
+ /* Reset activable image flag */
+ found_activable_image = false;
+ list_for_each_entry(attrs, &lfa_fw_images, image_node) {
+ if (attrs->fw_seq_id == -1)
+ continue; /* Invalid FW component */
+
+ if ((!attrs->activation_capable) || (!attrs->activation_pending))
+ continue; /* FW component is not activable */
+
+ /*
+ * Found an image that is activable.
+ * As the FW images tree is revised after activation, it is
+ * not ideal to invoke activation from inside
+ * list_for_each_entry() loop.
+ * So, set the flasg and exit loop.
+ */
+ found_activable_image = true;
+ break;
+ }
+
+ if (found_activable_image) {
+ ret = prime_fw_image(attrs);
+ if (ret) {
+ pr_err("Firmware prime failed: %s\n",
+ lfa_error_strings[-ret]);
+ return;
+ }
+
+ ret = activate_fw_image(attrs);
+ if (ret) {
+ pr_err("Firmware activation failed: %s\n",
+ lfa_error_strings[-ret]);
+ return;
+ }
+
+ pr_info("Firmware %s activation succeeded", attrs->image_name);
+ }
+ } while (found_activable_image);
+}
+
+static int lfa_probe(struct platform_device *pdev)
+{
+ acpi_status status;
+ acpi_handle handle = ACPI_HANDLE(&pdev->dev);
+
+ if (!handle)
+ return -ENODEV;
+
+ /* Register notify handler that indicates if LFA updates are available */
+ status = acpi_install_notify_handler(handle,
+ ACPI_DEVICE_NOTIFY, lfa_notify_handler, pdev);
+ if (ACPI_FAILURE(status))
+ return -EIO;
+
return 0;
}
+static void lfa_remove(struct platform_device *pdev)
+{
+ acpi_handle handle = ACPI_HANDLE(&pdev->dev);
+
+ if (handle)
+ acpi_remove_notify_handler(handle,
+ ACPI_DEVICE_NOTIFY, lfa_notify_handler);
+}
+
+static const struct acpi_device_id lfa_acpi_ids[] = {
+ {"ARML0003"},
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, lfa_acpi_ids);
+
+static struct platform_driver lfa_driver = {
+ .probe = lfa_probe,
+ .remove = lfa_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .acpi_match_table = ACPI_PTR(lfa_acpi_ids),
+ },
+};
+#endif
+
static int __init lfa_init(void)
{
struct arm_smccc_1_2_regs reg = { 0 };
@@ -679,6 +785,12 @@ static int __init lfa_init(void)
pr_info("Live Firmware Activation: detected v%ld.%ld\n",
reg.a0 >> 16, reg.a0 & 0xffff);
+#if defined(CONFIG_ACPI)
+ err = platform_driver_register(&lfa_driver);
+ if (err < 0)
+ pr_err("Platform driver register failed");
+#endif
+
lfa_dir = kobject_create_and_add("lfa", firmware_kobj);
if (!lfa_dir)
return -ENOMEM;
@@ -703,6 +815,9 @@ static void __exit lfa_exit(void)
mutex_unlock(&lfa_lock);
kobject_put(lfa_dir);
+#if defined(CONFIG_ACPI)
+ platform_driver_unregister(&lfa_driver);
+#endif
}
module_exit(lfa_exit);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] firmware: smccc: add timeout, touch wdt
From: Vedashree Vidwans @ 2026-02-10 22:40 UTC (permalink / raw)
To: salman.nabi, sudeep.holla, andre.przywara, lpieralisi,
mark.rutland, trilokkumar.soni
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar, Vedashree Vidwans
In-Reply-To: <20260210224023.2341728-1-vvidwans@nvidia.com>
Enhance PRIME/ACTIVATION functions to touch watchdog and implement
timeout mechanism. This update ensures that any potential hangs are
detected promptly and that the LFA process is allocated sufficient
execution time before the watchdog timer expires. These changes improve
overall system reliability by reducing the risk of undetected process
stalls and unexpected watchdog resets.
Signed-off-by: Vedashree Vidwans <vvidwans@nvidia.com>
---
drivers/firmware/smccc/lfa_fw.c | 40 +++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
index da6b54fe1685..b0ace6fc8dac 100644
--- a/drivers/firmware/smccc/lfa_fw.c
+++ b/drivers/firmware/smccc/lfa_fw.c
@@ -17,6 +17,9 @@
#include <linux/array_size.h>
#include <linux/list.h>
#include <linux/mutex.h>
+#include <linux/nmi.h>
+#include <linux/ktime.h>
+#include <linux/delay.h>
#undef pr_fmt
#define pr_fmt(fmt) "Arm LFA: " fmt
@@ -37,6 +40,14 @@
#define LFA_PRIME_CALL_AGAIN BIT(0)
#define LFA_ACTIVATE_CALL_AGAIN BIT(0)
+/* Prime loop limits, TODO: tune after testing */
+#define LFA_PRIME_BUDGET_US 30000000 /* 30s cap */
+#define LFA_PRIME_POLL_DELAY_US 10 /* 10us between polls */
+
+/* Activation loop limits, TODO: tune after testing */
+#define LFA_ACTIVATE_BUDGET_US 20000000 /* 20s cap */
+#define LFA_ACTIVATE_POLL_DELAY_US 10 /* 10us between polls */
+
/* LFA return values */
#define LFA_SUCCESS 0
#define LFA_NOT_SUPPORTED 1
@@ -219,6 +230,7 @@ static int call_lfa_activate(void *data)
struct image_props *attrs = data;
struct arm_smccc_1_2_regs args = { 0 };
struct arm_smccc_1_2_regs res = { 0 };
+ ktime_t end = ktime_add_us(ktime_get(), LFA_ACTIVATE_BUDGET_US);
args.a0 = LFA_1_0_FN_ACTIVATE;
args.a1 = attrs->fw_seq_id; /* fw_seq_id under consideration */
@@ -232,6 +244,8 @@ static int call_lfa_activate(void *data)
args.a2 = !(attrs->cpu_rendezvous_forced || attrs->cpu_rendezvous);
for (;;) {
+ /* Touch watchdog, ACTIVATE shouldn't take longer than watchdog_thresh */
+ touch_nmi_watchdog();
arm_smccc_1_2_invoke(&args, &res);
if ((long)res.a0 < 0) {
@@ -241,6 +255,15 @@ static int call_lfa_activate(void *data)
}
if (!(res.a1 & LFA_ACTIVATE_CALL_AGAIN))
break; /* ACTIVATE successful */
+
+ /* SMC returned with call_again flag set */
+ if (ktime_before(ktime_get(), end)) {
+ udelay(LFA_ACTIVATE_POLL_DELAY_US);
+ continue;
+ }
+
+ pr_err("ACTIVATE for image %s timed out", attrs->image_name);
+ return -ETIMEDOUT;
}
return res.a0;
@@ -290,6 +313,7 @@ static int prime_fw_image(struct image_props *attrs)
{
struct arm_smccc_1_2_regs args = { 0 };
struct arm_smccc_1_2_regs res = { 0 };
+ ktime_t end = ktime_add_us(ktime_get(), LFA_PRIME_BUDGET_US);
int ret;
mutex_lock(&lfa_lock);
@@ -317,6 +341,8 @@ static int prime_fw_image(struct image_props *attrs)
args.a0 = LFA_1_0_FN_PRIME;
args.a1 = attrs->fw_seq_id; /* fw_seq_id under consideration */
for (;;) {
+ /* Touch watchdog, PRIME shouldn't take longer than watchdog_thresh */
+ touch_nmi_watchdog();
arm_smccc_1_2_invoke(&args, &res);
if ((long)res.a0 < 0) {
@@ -328,6 +354,20 @@ static int prime_fw_image(struct image_props *attrs)
}
if (!(res.a1 & LFA_PRIME_CALL_AGAIN))
break; /* PRIME successful */
+
+ /* SMC returned with call_again flag set */
+ if (ktime_before(ktime_get(), end)) {
+ udelay(LFA_PRIME_POLL_DELAY_US);
+ continue;
+ }
+
+ pr_err("LFA_PRIME for image %s timed out", attrs->image_name);
+ mutex_unlock(&lfa_lock);
+
+ ret = lfa_cancel(attrs);
+ if (ret != 0)
+ return ret;
+ return -ETIMEDOUT;
}
mutex_unlock(&lfa_lock);
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] Arm LFA: timeout and ACPI platform driver support
From: Vedashree Vidwans @ 2026-02-10 22:40 UTC (permalink / raw)
To: salman.nabi, sudeep.holla, andre.przywara, lpieralisi,
mark.rutland, trilokkumar.soni
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar, Vedashree Vidwans
Hello,
(This is an updated version of the [RFC PATCH 0/5] Arm LFA: Improvements
and interrupt support [1], which builds on top of the latest [PATCH 0/1]
Arm Live Firmware activation (LFA) support [2].)
The latest LFA specification [3] updates the interface requirements for
ACPI-based platforms to use the ACPI Notify() signal, and
device-tree-based interface is unspecified. This series focuses on
reworking the LFA driver as an ACPI-backed platform driver, using ACPI
Notify() instead of a dedicated interrupt handler. The LFA core behavior
and sysfs layout remain as implemented by the base driver.
This series contains two incremental changes:
1. Add a timeout and watchdog touch during LFA operations, to make the
driver more robust in cases where firmware-side prime/activation phases
take longer than expected.
2. Register the LFA implementation as a platform driver, layering a
platform driver interface on top of the existing LFA core logic so the
functionality can be instantiated via a platform device.
Note:
This posting focuses on architectural and implementation improvements
for the LFA driver itself. It assumes that the bugs and issues raised
during review of the original "[PATCH 0/1] Arm Live Firmware activation
(LFA) support” [2] will be addressed directly by the author in that base
series. Once those fixes are in place, this series is intended to layer
on top cleanly.
Testing:
The final integrated driver (base LFA + these additions) has been tested
on Nvidia server platform with Linux kernel v6.16. The sysfs interface
was not exercised as part of this testing.
Regards,
Veda
[1] https://lore.kernel.org/linux-arm-kernel/20251208221319.1524888-1-vvidwans@nvidia.com/
[2] https://lore.kernel.org/linux-arm-kernel/20260119122729.287522-2-salman.nabi@arm.com/
[3] https://developer.arm.com/documentation/den0147/latest/
Vedashree Vidwans (2):
firmware: smccc: add timeout, touch wdt
firmware: smccc: register as platform driver
drivers/firmware/smccc/lfa_fw.c | 193 ++++++++++++++++++++++++++++----
1 file changed, 174 insertions(+), 19 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/1] firmware: smccc: add support for Live Firmware Activation (LFA)
From: Vedashree Vidwans @ 2026-02-10 22:20 UTC (permalink / raw)
To: Salman Nabi, andre.przywara, sudeep.holla, mark.rutland,
lpieralisi
Cc: ardb, chao.gao, linux-arm-kernel, linux-coco, linux-kernel,
sdonthineni, vsethi, vwadekar
In-Reply-To: <20260119122729.287522-2-salman.nabi@arm.com>
Hello,
I have tested this change on Nvidia server platform using Linux kernel
6.16. My testing was done on the final integrated version, which
includes a platform driver interface built on top of this patch. I will
be posting the platform driver patch to LKML separately.
The final driver has been validated on target platform, except for the
sysfs interface which was not excercised during testing.
Tested-by: Vedashree Vidwans <vvidwans@nvidia.com>
Best,
Veda
On 1/19/26 04:27, Salman Nabi wrote:
> The Arm Live Firmware Activation (LFA) is a specification [1] to describe
> activating firmware components without a reboot. Those components
> (like TF-A's BL31, EDK-II, TF-RMM, secure paylods) would be updated the
> usual way: via fwupd, FF-A or other secure storage methods, or via some
> IMPDEF Out-Of-Bound method. The user can then activate this new firmware,
> at system runtime, without requiring a reboot.
> The specification covers the SMCCC interface to list and query available
> components and eventually trigger the activation.
>
> Add a new directory under /sys/firmware to present firmware components
> capable of live activation. Each of them is a directory under lfa/,
> and is identified via its GUID. The activation will be triggered by echoing
> "1" into the "activate" file:
> ==========================================
> /sys/firmware/lfa # ls -l . 6c*
> .:
> total 0
> drwxr-xr-x 2 0 0 0 Jan 19 11:33 47d4086d-4cfe-9846-9b95-2950cbbd5a00
> drwxr-xr-x 2 0 0 0 Jan 19 11:33 6c0762a6-12f2-4b56-92cb-ba8f633606d9
> drwxr-xr-x 2 0 0 0 Jan 19 11:33 d6d0eea7-fcea-d54b-9782-9934f234b6e4
>
> 6c0762a6-12f2-4b56-92cb-ba8f633606d9:
> total 0
> --w------- 1 0 0 4096 Jan 19 11:33 activate
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 activation_capable
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 activation_pending
> --w------- 1 0 0 4096 Jan 19 11:33 cancel
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 cpu_rendezvous
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 current_version
> -rw-r--r-- 1 0 0 4096 Jan 19 11:33 force_cpu_rendezvous
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 may_reset_cpu
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 name
> -r--r--r-- 1 0 0 4096 Jan 19 11:33 pending_version
> /sys/firmware/lfa/6c0762a6-12f2-4b56-92cb-ba8f633606d9 # grep . *
> grep: activate: Permission denied
> activation_capable:1
> activation_pending:1
> grep: cancel: Permission denied
> cpu_rendezvous:1
> current_version:0.0
> force_cpu_rendezvous:1
> may_reset_cpu:0
> name:TF-RMM
> pending_version:0.0
> /sys/firmware/lfa/6c0762a6-12f2-4b56-92cb-ba8f633606d9 # echo 1 > activate
> [ 2825.797871] Arm LFA: firmware activation succeeded.
> /sys/firmware/lfa/6c0762a6-12f2-4b56-92cb-ba8f633606d9 #
> ==========================================
>
> [1] https://developer.arm.com/documentation/den0147/latest/
>
> Signed-off-by: Salman Nabi <salman.nabi@arm.com>
> ---
> drivers/firmware/smccc/Kconfig | 8 +
> drivers/firmware/smccc/Makefile | 1 +
> drivers/firmware/smccc/lfa_fw.c | 668 ++++++++++++++++++++++++++++++++
> 3 files changed, 677 insertions(+)
> create mode 100644 drivers/firmware/smccc/lfa_fw.c
>
> diff --git a/drivers/firmware/smccc/Kconfig b/drivers/firmware/smccc/Kconfig
> index 15e7466179a6..ff7ca49486b0 100644
> --- a/drivers/firmware/smccc/Kconfig
> +++ b/drivers/firmware/smccc/Kconfig
> @@ -23,3 +23,11 @@ config ARM_SMCCC_SOC_ID
> help
> Include support for the SoC bus on the ARM SMCCC firmware based
> platforms providing some sysfs information about the SoC variant.
> +
> +config ARM_LFA
> + tristate "Arm Live Firmware activation support"
> + depends on HAVE_ARM_SMCCC_DISCOVERY
> + default y
> + help
> + Include support for triggering Live Firmware Activation, which
> + allows to upgrade certain firmware components without a reboot.
> diff --git a/drivers/firmware/smccc/Makefile b/drivers/firmware/smccc/Makefile
> index 40d19144a860..a6dd01558a94 100644
> --- a/drivers/firmware/smccc/Makefile
> +++ b/drivers/firmware/smccc/Makefile
> @@ -2,3 +2,4 @@
> #
> obj-$(CONFIG_HAVE_ARM_SMCCC_DISCOVERY) += smccc.o kvm_guest.o
> obj-$(CONFIG_ARM_SMCCC_SOC_ID) += soc_id.o
> +obj-$(CONFIG_ARM_LFA) += lfa_fw.o
> diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
> new file mode 100644
> index 000000000000..ce54049b7190
> --- /dev/null
> +++ b/drivers/firmware/smccc/lfa_fw.c
> @@ -0,0 +1,668 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2025 Arm Limited
> + */
> +
> +#include <linux/fs.h>
> +#include <linux/init.h>
> +#include <linux/kobject.h>
> +#include <linux/module.h>
> +#include <linux/stop_machine.h>
> +#include <linux/string.h>
> +#include <linux/sysfs.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/psci.h>
> +#include <uapi/linux/psci.h>
> +#include <linux/uuid.h>
> +#include <linux/array_size.h>
> +#include <linux/list.h>
> +#include <linux/mutex.h>
> +
> +#undef pr_fmt
> +#define pr_fmt(fmt) "Arm LFA: " fmt
> +
> +/* LFA v1.0b0 specification */
> +#define LFA_1_0_FN_BASE 0xc40002e0
> +#define LFA_1_0_FN(n) (LFA_1_0_FN_BASE + (n))
> +
> +#define LFA_1_0_FN_GET_VERSION LFA_1_0_FN(0)
> +#define LFA_1_0_FN_CHECK_FEATURE LFA_1_0_FN(1)
> +#define LFA_1_0_FN_GET_INFO LFA_1_0_FN(2)
> +#define LFA_1_0_FN_GET_INVENTORY LFA_1_0_FN(3)
> +#define LFA_1_0_FN_PRIME LFA_1_0_FN(4)
> +#define LFA_1_0_FN_ACTIVATE LFA_1_0_FN(5)
> +#define LFA_1_0_FN_CANCEL LFA_1_0_FN(6)
> +
> +/* CALL_AGAIN flags (returned by SMC) */
> +#define LFA_PRIME_CALL_AGAIN BIT(0)
> +#define LFA_ACTIVATE_CALL_AGAIN BIT(0)
> +
> +/* LFA return values */
> +#define LFA_SUCCESS 0
> +#define LFA_NOT_SUPPORTED 1
> +#define LFA_BUSY 2
> +#define LFA_AUTH_ERROR 3
> +#define LFA_NO_MEMORY 4
> +#define LFA_CRITICAL_ERROR 5
> +#define LFA_DEVICE_ERROR 6
> +#define LFA_WRONG_STATE 7
> +#define LFA_INVALID_PARAMETERS 8
> +#define LFA_COMPONENT_WRONG_STATE 9
> +#define LFA_INVALID_ADDRESS 10
> +#define LFA_ACTIVATION_FAILED 11
> +
> +#define LFA_ERROR_STRING(name) \
> + [name] = #name
> +
> +static const char * const lfa_error_strings[] = {
> + LFA_ERROR_STRING(LFA_SUCCESS),
> + LFA_ERROR_STRING(LFA_NOT_SUPPORTED),
> + LFA_ERROR_STRING(LFA_BUSY),
> + LFA_ERROR_STRING(LFA_AUTH_ERROR),
> + LFA_ERROR_STRING(LFA_NO_MEMORY),
> + LFA_ERROR_STRING(LFA_CRITICAL_ERROR),
> + LFA_ERROR_STRING(LFA_DEVICE_ERROR),
> + LFA_ERROR_STRING(LFA_WRONG_STATE),
> + LFA_ERROR_STRING(LFA_INVALID_PARAMETERS),
> + LFA_ERROR_STRING(LFA_COMPONENT_WRONG_STATE),
> + LFA_ERROR_STRING(LFA_INVALID_ADDRESS),
> + LFA_ERROR_STRING(LFA_ACTIVATION_FAILED)
> +};
> +
> +enum image_attr_names {
> + LFA_ATTR_NAME,
> + LFA_ATTR_CURRENT_VERSION,
> + LFA_ATTR_PENDING_VERSION,
> + LFA_ATTR_ACT_CAPABLE,
> + LFA_ATTR_ACT_PENDING,
> + LFA_ATTR_MAY_RESET_CPU,
> + LFA_ATTR_CPU_RENDEZVOUS,
> + LFA_ATTR_FORCE_CPU_RENDEZVOUS,
> + LFA_ATTR_ACTIVATE,
> + LFA_ATTR_CANCEL,
> + LFA_ATTR_NR_IMAGES
> +};
> +
> +struct image_props {
> + struct list_head image_node;
> + const char *image_name;
> + int fw_seq_id;
> + u64 current_version;
> + u64 pending_version;
> + bool activation_capable;
> + bool activation_pending;
> + bool may_reset_cpu;
> + bool cpu_rendezvous;
> + bool cpu_rendezvous_forced;
> + struct kobject *image_dir;
> + struct kobj_attribute image_attrs[LFA_ATTR_NR_IMAGES];
> +};
> +static LIST_HEAD(lfa_fw_images);
> +
> +/* A UUID split over two 64-bit registers */
> +struct uuid_regs {
> + u64 uuid_lo;
> + u64 uuid_hi;
> +};
> +
> +static const struct fw_image_uuid {
> + const char *name;
> + const char *uuid;
> +} fw_images_uuids[] = {
> + {
> + .name = "TF-A BL31 runtime",
> + .uuid = "47d4086d-4cfe-9846-9b95-2950cbbd5a00",
> + },
> + {
> + .name = "BL33 non-secure payload",
> + .uuid = "d6d0eea7-fcea-d54b-9782-9934f234b6e4",
> + },
> + {
> + .name = "TF-RMM",
> + .uuid = "6c0762a6-12f2-4b56-92cb-ba8f633606d9",
> + },
> +};
> +
> +static struct kobject *lfa_dir;
> +static DEFINE_MUTEX(lfa_lock);
> +static struct workqueue_struct *fw_images_update_wq;
> +static struct work_struct fw_images_update_work;
> +
> +static int update_fw_images_tree(void);
> +
> +static void delete_fw_image_node(struct image_props *attrs)
> +{
> + int i;
> +
> + for (i = 0; i < LFA_ATTR_NR_IMAGES; i++)
> + sysfs_remove_file(attrs->image_dir, &attrs->image_attrs[i].attr);
> +
> + kobject_put(attrs->image_dir);
> + list_del(&attrs->image_node);
> + kfree(attrs);
> +}
> +
> +static void remove_invalid_fw_images(struct work_struct *work)
> +{
> + struct image_props *attrs, *tmp;
> +
> + mutex_lock(&lfa_lock);
> +
> + /*
> + * Remove firmware images including directories that are no longer
> + * present in the LFA agent after updating the existing ones.
> + */
> + list_for_each_entry_safe(attrs, tmp, &lfa_fw_images, image_node) {
> + if (attrs->fw_seq_id == -1)
> + delete_fw_image_node(attrs);
> + }
> +
> + mutex_unlock(&lfa_lock);
> +}
> +
> +static void set_image_flags(struct image_props *attrs, int seq_id,
> + u32 image_flags, u64 reg_current_ver,
> + u64 reg_pending_ver)
> +{
> + attrs->fw_seq_id = seq_id;
> + attrs->current_version = reg_current_ver;
> + attrs->pending_version = reg_pending_ver;
> + attrs->activation_capable = !!(image_flags & BIT(0));
> + attrs->activation_pending = !!(image_flags & BIT(1));
> + attrs->may_reset_cpu = !!(image_flags & BIT(2));
> + /* cpu_rendezvous_optional bit has inverse logic in the spec */
> + attrs->cpu_rendezvous = !(image_flags & BIT(3));
> +}
> +
> +static unsigned long get_nr_lfa_components(void)
> +{
> + struct arm_smccc_1_2_regs reg = { 0 };
> +
> + reg.a0 = LFA_1_0_FN_GET_INFO;
> + reg.a1 = 0; /* lfa_info_selector = 0 */
> +
> + arm_smccc_1_2_invoke(®, ®);
> + if (reg.a0 != LFA_SUCCESS)
> + return reg.a0;
> +
> + return reg.a1;
> +}
> +
> +static int lfa_cancel(void *data)
> +{
> + struct image_props *attrs = data;
> + struct arm_smccc_1_2_regs reg = { 0 };
> +
> + reg.a0 = LFA_1_0_FN_CANCEL;
> + reg.a1 = attrs->fw_seq_id;
> + arm_smccc_1_2_invoke(®, ®);
> +
> + /*
> + * When firmware activation is called with "skip_cpu_rendezvous=1",
> + * LFA_CANCEL can fail with LFA_BUSY if the activation could not be
> + * cancelled.
> + */
> + if (reg.a0 == LFA_SUCCESS) {
> + pr_info("Activation cancelled for image %s\n",
> + attrs->image_name);
> + } else {
> + pr_err("Firmware activation could not be cancelled: %s\n",
> + lfa_error_strings[-reg.a0]);
> + return -EINVAL;
> + }
> +
> + return reg.a0;
> +}
> +
> +static int call_lfa_activate(void *data)
> +{
> + struct image_props *attrs = data;
> + struct arm_smccc_1_2_regs reg = { 0 };
> +
> + reg.a0 = LFA_1_0_FN_ACTIVATE;
> + reg.a1 = attrs->fw_seq_id; /* fw_seq_id under consideration */
> + /*
> + * As we do not support updates requiring a CPU reset (yet),
> + * we pass 0 in reg.a3 and reg.a4, holding the entry point and context
> + * ID respectively.
> + * cpu_rendezvous_forced is set by the administrator, via sysfs,
> + * cpu_rendezvous is dictated by each firmware component.
> + */
> + reg.a2 = !(attrs->cpu_rendezvous_forced || attrs->cpu_rendezvous);
> +
> + for (;;) {
> + arm_smccc_1_2_invoke(®, ®);
> +
> + if ((long)reg.a0 < 0) {
> + pr_err("ACTIVATE for image %s failed: %s\n",
> + attrs->image_name, lfa_error_strings[-reg.a0]);
> + return reg.a0;
> + }
> + if (!(reg.a1 & LFA_ACTIVATE_CALL_AGAIN))
> + break; /* ACTIVATE successful */
> + }
> +
> + return reg.a0;
> +}
> +
> +static int activate_fw_image(struct image_props *attrs)
> +{
> + int ret;
> +
> + mutex_lock(&lfa_lock);
> + if (attrs->cpu_rendezvous_forced || attrs->cpu_rendezvous)
> + ret = stop_machine(call_lfa_activate, attrs, cpu_online_mask);
> + else
> + ret = call_lfa_activate(attrs);
> +
> + if (ret != 0) {
> + mutex_unlock(&lfa_lock);
> + return lfa_cancel(attrs);
> + }
> +
> + /*
> + * Invalidate fw_seq_ids (-1) for all images as the seq_ids and the
> + * number of firmware images in the LFA agent may change after a
> + * successful activation attempt. Negate all image flags as well.
> + */
> + attrs = NULL;
> + list_for_each_entry(attrs, &lfa_fw_images, image_node) {
> + set_image_flags(attrs, -1, 0b1000, 0, 0);
> + }
> +
> + update_fw_images_tree();
> +
> + /*
> + * Removing non-valid image directories at the end of an activation.
> + * We can't remove the sysfs attributes while in the respective
> + * _store() handler, so have to postpone the list removal to a
> + * workqueue.
> + */
> + INIT_WORK(&fw_images_update_work, remove_invalid_fw_images);
> + queue_work(fw_images_update_wq, &fw_images_update_work);
> + mutex_unlock(&lfa_lock);
> +
> + return ret;
> +}
> +
> +static int prime_fw_image(struct image_props *attrs)
> +{
> + struct arm_smccc_1_2_regs reg = { 0 };
> + int ret;
> +
> + mutex_lock(&lfa_lock);
> + /* Avoid SMC calls on invalid firmware images */
> + if (attrs->fw_seq_id == -1) {
> + pr_err("Arm LFA: Invalid firmware sequence id\n");
> + mutex_unlock(&lfa_lock);
> +
> + return -ENODEV;
> + }
> +
> + if (attrs->may_reset_cpu) {
> + pr_err("CPU reset not supported by kernel driver\n");
> + mutex_unlock(&lfa_lock);
> +
> + return -EINVAL;
> + }
> +
> + /*
> + * LFA_PRIME/ACTIVATE will return 1 in reg.a1 if the firmware
> + * priming/activation is still in progress. In that case
> + * LFA_PRIME/ACTIVATE will need to be called again.
> + * reg.a1 will become 0 once the prime/activate process completes.
> + */
> + reg.a0 = LFA_1_0_FN_PRIME;
> + reg.a1 = attrs->fw_seq_id; /* fw_seq_id under consideration */
> + for (;;) {
> + arm_smccc_1_2_invoke(®, ®);
> +
> + if ((long)reg.a0 < 0) {
> + pr_err("LFA_PRIME for image %s failed: %s\n",
> + attrs->image_name, lfa_error_strings[-reg.a0]);
> + mutex_unlock(&lfa_lock);
> +
> + return reg.a0;
> + }
> + if (!(reg.a1 & LFA_PRIME_CALL_AGAIN)) {
> + ret = 0;
> + break; /* PRIME successful */
> + }
> + }
> +
> + mutex_unlock(&lfa_lock);
> + return ret;
> +}
> +
> +static ssize_t name_show(struct kobject *kobj, struct kobj_attribute *attr,
> + char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_NAME]);
> +
> + return sysfs_emit(buf, "%s\n", attrs->image_name);
> +}
> +
> +static ssize_t activation_capable_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_ACT_CAPABLE]);
> +
> + return sysfs_emit(buf, "%d\n", attrs->activation_capable);
> +}
> +
> +static ssize_t activation_pending_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_ACT_PENDING]);
> + struct arm_smccc_1_2_regs reg = { 0 };
> +
> + /*
> + * Activation pending status can change anytime thus we need to update
> + * and return its current value
> + */
> + reg.a0 = LFA_1_0_FN_GET_INVENTORY;
> + reg.a1 = attrs->fw_seq_id;
> + arm_smccc_1_2_invoke(®, ®);
> + if (reg.a0 == LFA_SUCCESS)
> + attrs->activation_pending = !!(reg.a3 & BIT(1));
> +
> + return sysfs_emit(buf, "%d\n", attrs->activation_pending);
> +}
> +
> +static ssize_t may_reset_cpu_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_MAY_RESET_CPU]);
> +
> + return sysfs_emit(buf, "%d\n", attrs->may_reset_cpu);
> +}
> +
> +static ssize_t cpu_rendezvous_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_CPU_RENDEZVOUS]);
> +
> + return sysfs_emit(buf, "%d\n", attrs->cpu_rendezvous);
> +}
> +
> +static ssize_t force_cpu_rendezvous_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_FORCE_CPU_RENDEZVOUS]);
> + int ret;
> +
> + ret = kstrtobool(buf, &attrs->cpu_rendezvous_forced);
> + if (ret)
> + return ret;
> +
> + return count;
> +}
> +
> +static ssize_t force_cpu_rendezvous_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_FORCE_CPU_RENDEZVOUS]);
> +
> + return sysfs_emit(buf, "%d\n", attrs->cpu_rendezvous_forced);
> +}
> +
> +static ssize_t current_version_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_CURRENT_VERSION]);
> + u32 maj, min;
> +
> + maj = attrs->current_version >> 32;
> + min = attrs->current_version & 0xffffffff;
> + return sysfs_emit(buf, "%u.%u\n", maj, min);
> +}
> +
> +static ssize_t pending_version_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_ACT_PENDING]);
> + struct arm_smccc_1_2_regs reg = { 0 };
> + u32 maj, min;
> +
> + /*
> + * Similar to activation pending, this value can change following an
> + * update, we need to retrieve fresh info instead of stale information.
> + */
> + reg.a0 = LFA_1_0_FN_GET_INVENTORY;
> + reg.a1 = attrs->fw_seq_id;
> + arm_smccc_1_2_invoke(®, ®);
> + if (reg.a0 == LFA_SUCCESS) {
> + if (reg.a5 != 0 && attrs->activation_pending)
> + {
> + attrs->pending_version = reg.a5;
> + maj = reg.a5 >> 32;
> + min = reg.a5 & 0xffffffff;
> + }
> + }
> +
> + return sysfs_emit(buf, "%u.%u\n", maj, min);
> +}
> +
> +static ssize_t activate_store(struct kobject *kobj, struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_ACTIVATE]);
> + int ret;
> +
> + ret = prime_fw_image(attrs);
> + if (ret) {
> + pr_err("Firmware prime failed: %s\n",
> + lfa_error_strings[-ret]);
> + return -ECANCELED;
> + }
> +
> + ret = activate_fw_image(attrs);
> + if (ret) {
> + pr_err("Firmware activation failed: %s\n",
> + lfa_error_strings[-ret]);
> + return -ECANCELED;
> + }
> +
> + pr_info("Firmware activation succeeded\n");
> +
> + return count;
> +}
> +
> +static ssize_t cancel_store(struct kobject *kobj, struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct image_props *attrs = container_of(attr, struct image_props,
> + image_attrs[LFA_ATTR_CANCEL]);
> + int ret;
> +
> + ret = lfa_cancel(attrs);
> + if (ret != 0)
> + return ret;
> +
> + return count;
> +}
> +
> +static struct kobj_attribute image_attrs_group[LFA_ATTR_NR_IMAGES] = {
> + [LFA_ATTR_NAME] = __ATTR_RO(name),
> + [LFA_ATTR_CURRENT_VERSION] = __ATTR_RO(current_version),
> + [LFA_ATTR_PENDING_VERSION] = __ATTR_RO(pending_version),
> + [LFA_ATTR_ACT_CAPABLE] = __ATTR_RO(activation_capable),
> + [LFA_ATTR_ACT_PENDING] = __ATTR_RO(activation_pending),
> + [LFA_ATTR_MAY_RESET_CPU] = __ATTR_RO(may_reset_cpu),
> + [LFA_ATTR_CPU_RENDEZVOUS] = __ATTR_RO(cpu_rendezvous),
> + [LFA_ATTR_FORCE_CPU_RENDEZVOUS] = __ATTR_RW(force_cpu_rendezvous),
> + [LFA_ATTR_ACTIVATE] = __ATTR_WO(activate),
> + [LFA_ATTR_CANCEL] = __ATTR_WO(cancel)
> +};
> +
> +static void clean_fw_images_tree(void)
> +{
> + struct image_props *attrs, *tmp;
> +
> + list_for_each_entry_safe(attrs, tmp, &lfa_fw_images, image_node)
> + delete_fw_image_node(attrs);
> +}
> +
> +static int update_fw_image_node(char *fw_uuid, int seq_id,
> + u32 image_flags, u64 reg_current_ver,
> + u64 reg_pending_ver)
> +{
> + const char *image_name = "(unknown)";
> + struct image_props *attrs;
> + int ret;
> +
> + /*
> + * If a fw_image is already in the images list then we just update
> + * its flags and seq_id instead of trying to recreate it.
> + */
> + list_for_each_entry(attrs, &lfa_fw_images, image_node) {
> + if (!strcmp(attrs->image_dir->name, fw_uuid)) {
> + set_image_flags(attrs, seq_id, image_flags,
> + reg_current_ver, reg_pending_ver);
> + return 0;
> + }
> + }
> +
> + attrs = kzalloc(sizeof(*attrs), GFP_KERNEL);
> + if (!attrs)
> + return -ENOMEM;
> +
> + for (int i = 0; i < ARRAY_SIZE(fw_images_uuids); i++) {
> + if (!strcmp(fw_images_uuids[i].uuid, fw_uuid))
> + image_name = fw_images_uuids[i].name;
> + }
> +
> + attrs->image_dir = kobject_create_and_add(fw_uuid, lfa_dir);
> + if (!attrs->image_dir)
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&attrs->image_node);
> + attrs->image_name = image_name;
> + attrs->cpu_rendezvous_forced = 1;
> + set_image_flags(attrs, seq_id, image_flags, reg_current_ver,
> + reg_pending_ver);
> +
> + /*
> + * The attributes for each sysfs file are constant (handler functions,
> + * name and permissions are the same within each directory), but we
> + * need a per-directory copy regardless, to get a unique handle
> + * for each directory, so that container_of can do its magic.
> + * Also this requires an explicit sysfs_attr_init(), since it's a new
> + * copy, to make LOCKDEP happy.
> + */
> + memcpy(attrs->image_attrs, image_attrs_group,
> + sizeof(attrs->image_attrs));
> + for (int i = 0; i < LFA_ATTR_NR_IMAGES; i++) {
> + struct attribute *attr = &attrs->image_attrs[i].attr;
> +
> + sysfs_attr_init(attr);
> + ret = sysfs_create_file(attrs->image_dir, attr);
> + if (ret) {
> + pr_err("creating sysfs file for uuid %s: %d\n",
> + fw_uuid, ret);
> + clean_fw_images_tree();
> +
> + return ret;
> + }
> + }
> + list_add(&attrs->image_node, &lfa_fw_images);
> +
> + return ret;
> +}
> +
> +static int update_fw_images_tree(void)
> +{
> + struct arm_smccc_1_2_regs reg = { 0 };
> + struct uuid_regs image_uuid;
> + char image_id_str[40];
> + int ret, num_of_components;
> +
> + num_of_components = get_nr_lfa_components();
> + if (num_of_components <= 0) {
> + pr_err("Error getting number of LFA components\n");
> + return -ENODEV;
> + }
> +
> + for (int i = 0; i < num_of_components; i++) {
> + reg.a0 = LFA_1_0_FN_GET_INVENTORY;
> + reg.a1 = i; /* fw_seq_id under consideration */
> + arm_smccc_1_2_invoke(®, ®);
> + if (reg.a0 == LFA_SUCCESS) {
> + image_uuid.uuid_lo = reg.a1;
> + image_uuid.uuid_hi = reg.a2;
> +
> + snprintf(image_id_str, sizeof(image_id_str), "%pUb",
> + &image_uuid);
> + ret = update_fw_image_node(image_id_str, i,
> + reg.a3, reg.a4, reg.a5);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int __init lfa_init(void)
> +{
> + struct arm_smccc_1_2_regs reg = { 0 };
> + int err;
> +
> + reg.a0 = LFA_1_0_FN_GET_VERSION;
> + arm_smccc_1_2_invoke(®, ®);
> + if (reg.a0 == -LFA_NOT_SUPPORTED) {
> + pr_info("Live Firmware activation: no firmware agent found\n");
> + return -ENODEV;
> + }
> +
> + fw_images_update_wq = alloc_workqueue("fw_images_update_wq",
> + WQ_UNBOUND | WQ_MEM_RECLAIM, 1);
> + if (!fw_images_update_wq) {
> + pr_err("Live Firmware Activation: Failed to allocate workqueue.\n");
> +
> + return -ENOMEM;
> + }
> +
> + pr_info("Live Firmware Activation: detected v%ld.%ld\n",
> + reg.a0 >> 16, reg.a0 & 0xffff);
> +
> + lfa_dir = kobject_create_and_add("lfa", firmware_kobj);
> + if (!lfa_dir)
> + return -ENOMEM;
> +
> + mutex_lock(&lfa_lock);
> + err = update_fw_images_tree();
> + if (err != 0)
> + kobject_put(lfa_dir);
> +
> + mutex_unlock(&lfa_lock);
> + return err;
> +}
> +module_init(lfa_init);
> +
> +static void __exit lfa_exit(void)
> +{
> + flush_workqueue(fw_images_update_wq);
> + destroy_workqueue(fw_images_update_wq);
> +
> + mutex_lock(&lfa_lock);
> + clean_fw_images_tree();
> + mutex_unlock(&lfa_lock);
> +
> + kobject_put(lfa_dir);
> +}
> +module_exit(lfa_exit);
> +
> +MODULE_DESCRIPTION("ARM Live Firmware Activation (LFA)");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Dave Hansen @ 2026-02-10 22:19 UTC (permalink / raw)
To: Edgecombe, Rick P, seanjc@google.com, x86@kernel.org,
dave.hansen@linux.intel.com, kas@kernel.org, bp@alien8.de,
mingo@redhat.com, tglx@kernel.org, pbonzini@redhat.com
Cc: Huang, Kai, ackerleytng@google.com, sagis@google.com,
Annapurve, Vishal, linux-kernel@vger.kernel.org, Zhao, Yan Y,
Li, Xiaoyao, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
Yamahata, Isaku, binbin.wu@linux.intel.com
In-Reply-To: <ebd424718bb0b2754b7cbacb277746a3076faea3.camel@intel.com>
On 2/10/26 14:15, Edgecombe, Rick P wrote:
> I'm wasn't familiar with atomic_dec_and_lock(). I'm guess the atomic
> part doesn't cover both decrementing *and* taking the lock?
Right. Only 1=>0 is under the lock. All other decs are outside the lock.
It doesn't do the atomic and the lock "atomically together" somehow.
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Edgecombe, Rick P @ 2026-02-10 22:15 UTC (permalink / raw)
To: Hansen, Dave, seanjc@google.com, x86@kernel.org,
dave.hansen@linux.intel.com, kas@kernel.org, bp@alien8.de,
mingo@redhat.com, tglx@kernel.org, pbonzini@redhat.com
Cc: Huang, Kai, ackerleytng@google.com, sagis@google.com,
Annapurve, Vishal, linux-kernel@vger.kernel.org, Zhao, Yan Y,
Li, Xiaoyao, kvm@vger.kernel.org, linux-coco@lists.linux.dev,
Yamahata, Isaku, binbin.wu@linux.intel.com
In-Reply-To: <655724f8-0098-40ee-a097-ce4c0249933d@intel.com>
On Tue, 2026-02-10 at 09:44 -0800, Dave Hansen wrote:
> This looks funky.
>
> Right now, this is:
>
> spin_lock(pamt_lock)
> atomic_inc/dec(fine-grained-refcount)
> tdcall_blah_blah()
> spin_unlock(pamt_lock)
>
> Where it *always* acquires the global lock when DPAMT is supported.
> Couldn't we optimize it so that it only acquires it when it has to keep
> the refcount stable at zero?
>
> Roughly:
>
> slow_path = atomic_dec_and_lock(fine-grained-refcount,
> pamt_lock)
> if (!slow_path)
> goto out;
>
> // fine-grained-refcount==0 and must stay that way with
> // pamt_lock held. Remove the DPAMT pages:
> tdh_phymem_pamt_remove(page, pamt_pa_array)
> out:
> spin_unlock(pamt_lock)
>
> On the acquire side, you do:
>
> fast_path = atomic_inc_not_zero(fine-grained-refcount)
> if (fast_path)
> return;
>
> // slow path:
> spin_lock(pamt_lock)
>
> // Was the race lost with another 0=>1 increment?
> if (atomic_read(fine-grained-refcount) > 0)
> goto out_inc
>
> tdh_phymem_pamt_add(page, pamt_pa_array)
> // Inc after the TDCALL so another thread won't race ahead of us
> // and try to use a non-existent PAMT entry
> out_inc:
> atomic_inc(fine-grained-refcount)
> spin_unlock(pamt_lock)
>
> Then, at least only the 0=>1 and 1=>0 transitions need the global lock.
> The fast paths only touch the refcount which isn't shared nearly as much
> as the global lock.
This is pretty much what the next patch does "x86/virt/tdx: Optimize
tdx_alloc/free_control_page() helpers", although it doesn't use the
atomic_dec_and_lock() helpers. There are a few extra considerations. The get/put
fast paths can race, so inside the lock it has to double check that work or
otherwise handle the race. This lead the code to be complex enough that it was
split into too patches "dumb and correct" and "smart and complicated".
I'm wasn't familiar with atomic_dec_and_lock(). I'm guess the atomic part
doesn't cover both decrementing *and* taking the lock?
^ permalink raw reply
* Re: [PATCH 4/5] dma-buf: heaps: allow heap to specify valid heap flags
From: John Stultz @ 2026-02-10 20:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, tjmercier,
christian.koenig, m.szyprowski, robin.murphy, jgg, sean.anderson,
ptesarik, catalin.marinas, aneesh.kumar, suzuki.poulose,
steven.price, thomas.lendacky, john.allen, ashish.kalra,
suravee.suthikulpanit, linux-coco
In-Reply-To: <20260210124819.GC12887@unreal>
On Tue, Feb 10, 2026 at 4:48 AM Leon Romanovsky <leon@kernel.org> wrote:
> On Tue, Feb 10, 2026 at 10:05:14AM +0100, Jiri Pirko wrote:
> > Mon, Feb 09, 2026 at 09:08:03PM +0100, jstultz@google.com wrote:
> > >On Mon, Feb 9, 2026 at 7:38 AM Jiri Pirko <jiri@resnulli.us> wrote:
> > >>
> > >> From: Jiri Pirko <jiri@nvidia.com>
> > >>
> > >> Currently the flags, which are unused, are validated for all heaps.
> > >> Since the follow-up patch introduces a flag valid for only one of the
> > >> heaps, allow to specify the valid flags per-heap.
> > >
> > >I'm not really in this space anymore, so take my feedback with a grain of salt.
> > >
> > >While the heap allocate flags argument is unused, it was intended to
> > >be used for generic allocation flags that would apply to all or at
> > >least a wide majority of heaps.
> > >
> > >It was definitely not added to allow for per-heap or heap specific
> > >flags (as this patch tries to utilize it). That was the mess we had
> > >with ION driver that we were trying to avoid.
> > >
> > >The intent of dma-buf heaps is to try to abstract all the different
> > >device memory constraints so there only needs to be a [usage] ->
> > >[heap] mapping, and otherwise userland can be generalized so that it
> > >doesn't need to be re-written to work with different devices/memory
> > >types. Adding heap-specific allocation flags prevents that
> > >generalization.
> > >
> > >So instead of adding heap specific flags, the general advice has been
> > >to add a separate heap name for the flag property.
> >
> > Right, my original idea was to add a separate heap. Then I spotted the
> > flags and seemed like a great fit. Was not aware or the history or
> > original intention. Would be probably good to document it for
> > future generations.
> >
> > So instead of flag, I will add heap named something
> > like "system_cc_decrypted" to implement this.
>
> It is problematic to expose a user‑visible API that depends on a name.
> Such a design limits our ability to extend the functionality in the
> future, should new use cases arise.
Yes, how userland chooses a heap name is an open problem.
The difficulty is that userland is the only thing that knows what
devices the buffer will be shared (and this knowledge may be
incomplete if userland passes a buffer between processes) with, so it
has to pick. But the kernel doesn't give it a way to solve the
constraints of what memory types work with what devices. There have
been some proposals for device sysfs directories to have links to heap
types they support, but that also requires every driver to understand
every heap type. And then you get to the fact that performance is what
folks really want, not compatibility and that may require some system
specific knowledge to decide.
The working solution right now is to have the system provide a [use]
-> [heap] mapping for a specific system.
I think of this as similar to the vfs and /etc/fstab. So /home/ might
be /dev/sdb1 on one device or dev/sda1 on another. You need some
system specific configuration.
In Android, this mapping is done by Gralloc, so buffers are requested
for a use and then Gralloc decides which heap to allocated from.
Unfortunately there doesn't seem to be a similar standard convention
elsewhere. And I'll admit even then the enumeration of uses/pipelines
in some general form is also difficult problem (and is somewhat more
bounded for Android).
thanks
-john
^ permalink raw reply
* Re: [RFC PATCH v5 08/45] KVM: x86/mmu: Propagate mirror SPTE removal to S-EPT in handle_changed_spte()
From: Sean Christopherson @ 2026-02-10 19:52 UTC (permalink / raw)
To: Yan Zhao
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Vishal Annapurve, Ackerley Tng,
Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYsOV7Q5FTWo+6/x@yzhao56-desk.sh.intel.com>
On Tue, Feb 10, 2026, Yan Zhao wrote:
> On Fri, Feb 06, 2026 at 09:41:38AM -0800, Sean Christopherson wrote:
> > On Fri, Feb 06, 2026, Yan Zhao wrote:
> > @@ -559,30 +559,31 @@ static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
> > * SPTE being converted to a hugepage (leaf) or being zapped. Shadow
> > * pages are kernel allocations and should never be migrated.
> > *
> > - * When modifying leaf entries in mirrored page tables, propagate the
> > - * changes to the external SPTE. Bug the VM on failure, as callers
> > - * aren't prepared to handle errors, e.g. due to lock contention in the
> > - * TDX-Module. Note, changes to non-leaf mirror SPTEs are handled by
> > - * handle_removed_pt() (the TDX-Module requires that child entries are
> > - * removed before the parent SPTE), and changes to non-present mirror
> > - * SPTEs are handled by __tdp_mmu_set_spte_atomic() (KVM needs to set
> > - * the external SPTE while the mirror SPTE is frozen so that installing
> > - * a new SPTE is effectively an atomic operation).
> > + * When modifying leaf entries in mirrored page tables, propagate all
> > + * changes to the external SPTE.
> > */
> > if (was_present && !was_leaf &&
> > (is_leaf || !is_present || WARN_ON_ONCE(pfn_changed)))
> > handle_removed_pt(kvm, spte_to_child_pt(old_spte, level), shared);
> > - else if (was_leaf && is_mirror_sptep(sptep))
> > - KVM_BUG_ON(kvm_x86_call(set_external_spte)(kvm, gfn, old_spte,
> > - new_spte, level), kvm);
> > + else if (is_mirror_sptep(sptep))
> > + return kvm_x86_call(set_external_spte)(kvm, gfn, old_spte,
> > + new_spte, level);
> For TDX's future implementation of set_external_spte() for split splitting,
> could we add a new param "bool shared" to op set_external_spte() in the
> future? i.e.,
> - when tdx_sept_split_private_spte() is invoked under write mmu_lock, it calls
> tdh_do_no_vcpus() to retry BUSY error, and TDX_BUG_ON_2() then.
> - when tdx_sept_split_private_spte() is invoked under read mmu_lock
> (in the future when calling tdh_mem_range_block() in unnecessary), it could
> directly return BUSY to TDP MMU on contention.
Yeah, I have no objection to using @shared for things like that.
> > + return 0;
> > +}
> > +
> > +static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
> > + gfn_t gfn, u64 old_spte, u64 new_spte,
> > + int level, bool shared)
> > +{
> Do we need "WARN_ON_ONCE(is_mirror_sptep(sptep) && shared)" here ?
No, because I want to call this code for all paths, including the fault path.
> > + KVM_BUG_ON(__handle_changed_spte(kvm, as_id, sptep, gfn, old_spte,
> > + new_spte, level, shared), kvm);
> > }
>
>
>
> >
> > static inline int __must_check __tdp_mmu_set_spte_atomic(struct kvm *kvm,
> > struct tdp_iter *iter,
> > u64 new_spte)
> > {
> > - u64 *raw_sptep = rcu_dereference(iter->sptep);
> > -
> > /*
> > * The caller is responsible for ensuring the old SPTE is not a FROZEN
> > * SPTE. KVM should never attempt to zap or manipulate a FROZEN SPTE,
> > @@ -591,40 +592,6 @@ static inline int __must_check __tdp_mmu_set_spte_atomic(struct kvm *kvm,
> > */
> > WARN_ON_ONCE(iter->yielded || is_frozen_spte(iter->old_spte));
> >
> > - if (is_mirror_sptep(iter->sptep) && !is_frozen_spte(new_spte)) {
> > - int ret;
> > -
> > - /*
> > - * KVM doesn't currently support zapping or splitting mirror
> > - * SPTEs while holding mmu_lock for read.
> > - */
> > - if (KVM_BUG_ON(is_shadow_present_pte(iter->old_spte), kvm) ||
> > - KVM_BUG_ON(!is_shadow_present_pte(new_spte), kvm))
> > - return -EBUSY;
> > -
> > - /*
> > - * Temporarily freeze the SPTE until the external PTE operation
> > - * has completed, e.g. so that concurrent faults don't attempt
> > - * to install a child PTE in the external page table before the
> > - * parent PTE has been written.
> > - */
> > - if (!try_cmpxchg64(raw_sptep, &iter->old_spte, FROZEN_SPTE))
> > - return -EBUSY;
> > -
> > - /*
> > - * Update the external PTE. On success, set the mirror SPTE to
> > - * the desired value. On failure, restore the old SPTE so that
> > - * the SPTE isn't frozen in perpetuity.
> > - */
> > - ret = kvm_x86_call(set_external_spte)(kvm, iter->gfn, iter->old_spte,
> > - new_spte, iter->level);
> > - if (ret)
> > - __kvm_tdp_mmu_write_spte(iter->sptep, iter->old_spte);
> > - else
> > - __kvm_tdp_mmu_write_spte(iter->sptep, new_spte);
> > - return ret;
> > - }
> > -
> > /*
> > * Note, fast_pf_fix_direct_spte() can also modify TDP MMU SPTEs and
> > * does not hold the mmu_lock. On failure, i.e. if a different logical
> > @@ -632,7 +599,7 @@ static inline int __must_check __tdp_mmu_set_spte_atomic(struct kvm *kvm,
> > * the current value, so the caller operates on fresh data, e.g. if it
> > * retries tdp_mmu_set_spte_atomic()
> > */
> > - if (!try_cmpxchg64(raw_sptep, &iter->old_spte, new_spte))
> > + if (!try_cmpxchg64(rcu_dereference(iter->sptep), &iter->old_spte, new_spte))
> > return -EBUSY;
> >
> > return 0;
> > @@ -663,14 +630,44 @@ static inline int __must_check tdp_mmu_set_spte_atomic(struct kvm *kvm,
> >
> > lockdep_assert_held_read(&kvm->mmu_lock);
> >
> > - ret = __tdp_mmu_set_spte_atomic(kvm, iter, new_spte);
> >
> > + /* KVM should never freeze SPTEs using higher level APIs. */
> > + KVM_MMU_WARN_ON(is_frozen_spte(new_spte));
> What about
> KVM_MMU_WARN_ON(is_frozen_spte(new_spte) ||
> is_frozen_spte(iter->old_spte) || iter->yielded);
>
> > + /*
> > + * Temporarily freeze the SPTE until the external PTE operation has
> > + * completed (unless the new SPTE itself will be frozen), e.g. so that
> > + * concurrent faults don't attempt to install a child PTE in the
> > + * external page table before the parent PTE has been written, or try
> > + * to re-install a page table before the old one was removed.
> > + */
> > + if (is_mirror_sptep(iter->sptep))
> > + ret = __tdp_mmu_set_spte_atomic(kvm, iter, FROZEN_SPTE);
> > + else
> > + ret = __tdp_mmu_set_spte_atomic(kvm, iter, new_spte);
> and invoking open code try_cmpxchg64() directly?
No, because __tdp_mmu_set_spte_atomic() is still used by kvm_tdp_mmu_age_spte(),
and the yielded/frozen rules apply there as well.
> > + /*
> > + * Unfreeze the mirror SPTE. If updating the external SPTE failed,
> > + * restore the old SPTE so that the SPTE isn't frozen in perpetuity,
> > + * otherwise set the mirror SPTE to the new desired value.
> > + */
> > + if (is_mirror_sptep(iter->sptep)) {
> > + if (ret)
> > + __kvm_tdp_mmu_write_spte(iter->sptep, iter->old_spte);
> > + else
> > + __kvm_tdp_mmu_write_spte(iter->sptep, new_spte);
> > + } else {
> > + /*
> > + * Bug the VM if handling the change failed, as failure is only
> > + * allowed if KVM couldn't update the external SPTE.
> > + */
> > + KVM_BUG_ON(ret, kvm);
> > + }
> > + return ret;
> > }
> One concern for tdp_mmu_set_spte_atomic() to handle mirror SPTEs:
> - Previously
> 1. set *iter->sptep to FROZEN_SPTE.
> 2. kvm_x86_call(set_external_spte)(old_spte, new_spte)
> 3. set *iter->sptep to new_spte
>
> - Now with this diff
> 1. set *iter->sptep to FROZEN_SPTE.
> 2. __handle_changed_spte()
> --> kvm_x86_call(set_external_spte)(iter->sptep, old_spte, new_spte)
Note, iter->sptep isn't passed to set_external_spte(), the invocation for that is:
return kvm_x86_call(set_external_spte)(kvm, gfn, old_spte,
new_spte, level);
> 3. set *iter->sptep to new_spte
>
> what if __handle_changed_spte() reads *iter->sptep in step 2?
For the most part, "don't do that". There are an infinite number of "what ifs".
I agree that re-reading iter->sptep is slightly more likely than other "what ifs",
but then if we convert to a boolean it creates the "what if we swap the order of
@as_id and @is_mirror_sp"? Given that @old_spte is provided, IMO re-reading the
SPTE from memory will stand out.
That said, I think we can have the best of both worlds. Rather than pass @as_id
and @sptep, pass the @sp, i.e. the owning kvm_mmu_page. That would address your
concern about re-reading the sptep, without needing another boolean.
E.g. slotted in as a cleanup somewhere earlier:
---
arch/x86/kvm/mmu/tdp_mmu.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index 732548a678d8..d395da35d5e4 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -326,7 +326,7 @@ void kvm_tdp_mmu_alloc_root(struct kvm_vcpu *vcpu, bool mirror)
}
}
-static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
+static void handle_changed_spte(struct kvm *kvm, struct kvm_mmu_page *sp,
gfn_t gfn, u64 old_spte, u64 new_spte,
int level, bool shared);
@@ -458,8 +458,7 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared)
old_spte = kvm_tdp_mmu_write_spte(sptep, old_spte,
FROZEN_SPTE, level);
}
- handle_changed_spte(kvm, kvm_mmu_page_as_id(sp), sptep, gfn,
- old_spte, FROZEN_SPTE, level, shared);
+ handle_changed_spte(kvm, sp, gfn, old_spte, FROZEN_SPTE, level, shared);
}
if (is_mirror_sp(sp))
@@ -471,8 +470,7 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared)
/**
* __handle_changed_spte - handle bookkeeping associated with an SPTE change
* @kvm: kvm instance
- * @as_id: the address space of the paging structure the SPTE was a part of
- * @sptep: pointer to the SPTE
+ * @sp: the page table in which the SPTE resides
* @gfn: the base GFN that was mapped by the SPTE
* @old_spte: The value of the SPTE before the change
* @new_spte: The value of the SPTE after the change
@@ -485,7 +483,7 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared)
* dirty logging updates are handled in common code, not here (see make_spte()
* and fast_pf_fix_direct_spte()).
*/
-static int __handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
+static int __handle_changed_spte(struct kvm *kvm, struct kvm_mmu_page *sp,
gfn_t gfn, u64 old_spte, u64 new_spte,
int level, bool shared)
{
@@ -494,6 +492,7 @@ static int __handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
bool was_leaf = was_present && is_last_spte(old_spte, level);
bool is_leaf = is_present && is_last_spte(new_spte, level);
bool pfn_changed = spte_to_pfn(old_spte) != spte_to_pfn(new_spte);
+ int as_id = kvm_mmu_page_as_id(sp);
WARN_ON_ONCE(level > PT64_ROOT_MAX_LEVEL);
WARN_ON_ONCE(level < PG_LEVEL_4K);
@@ -570,19 +569,19 @@ static int __handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
if (was_present && !was_leaf &&
(is_leaf || !is_present || WARN_ON_ONCE(pfn_changed)))
handle_removed_pt(kvm, spte_to_child_pt(old_spte, level), shared);
- else if (is_mirror_sptep(sptep))
+ else if (is_mirror_sp(sp))
return kvm_x86_call(set_external_spte)(kvm, gfn, old_spte,
new_spte, level);
return 0;
}
-static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
+static void handle_changed_spte(struct kvm *kvm, struct kvm_mmu_page *sp,
gfn_t gfn, u64 old_spte, u64 new_spte,
int level, bool shared)
{
- KVM_BUG_ON(__handle_changed_spte(kvm, as_id, sptep, gfn, old_spte,
- new_spte, level, shared), kvm);
+ KVM_BUG_ON(__handle_changed_spte(kvm, sp, gfn, old_spte, new_spte,
+ level, shared), kvm);
}
static inline int __must_check __tdp_mmu_set_spte_atomic(struct kvm *kvm,
@@ -631,6 +630,7 @@ static inline int __must_check tdp_mmu_set_spte_atomic(struct kvm *kvm,
struct tdp_iter *iter,
u64 new_spte)
{
+ struct kvm_mmu_page *sp = sptep_to_sp(rcu_dereference(iter->sptep));
int ret;
lockdep_assert_held_read(&kvm->mmu_lock);
@@ -652,8 +652,8 @@ static inline int __must_check tdp_mmu_set_spte_atomic(struct kvm *kvm,
if (ret)
return ret;
- ret = __handle_changed_spte(kvm, iter->as_id, iter->sptep, iter->gfn,
- iter->old_spte, new_spte, iter->level, true);
+ ret = __handle_changed_spte(kvm, sp, iter->gfn, iter->old_spte,
+ new_spte, iter->level, true);
/*
* Unfreeze the mirror SPTE. If updating the external SPTE failed,
@@ -678,7 +678,6 @@ static inline int __must_check tdp_mmu_set_spte_atomic(struct kvm *kvm,
/*
* tdp_mmu_set_spte - Set a TDP MMU SPTE and handle the associated bookkeeping
* @kvm: KVM instance
- * @as_id: Address space ID, i.e. regular vs. SMM
* @sptep: Pointer to the SPTE
* @old_spte: The current value of the SPTE
* @new_spte: The new value that will be set for the SPTE
@@ -691,6 +690,8 @@ static inline int __must_check tdp_mmu_set_spte_atomic(struct kvm *kvm,
static u64 tdp_mmu_set_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
u64 old_spte, u64 new_spte, gfn_t gfn, int level)
{
+ struct kvm_mmu_page *sp = sptep_to_sp(rcu_dereference(sptep));
+
lockdep_assert_held_write(&kvm->mmu_lock);
/*
@@ -704,7 +705,7 @@ static u64 tdp_mmu_set_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
old_spte = kvm_tdp_mmu_write_spte(sptep, old_spte, new_spte, level);
- handle_changed_spte(kvm, as_id, sptep, gfn, old_spte, new_spte, level, false);
+ handle_changed_spte(kvm, sp, gfn, old_spte, new_spte, level, false);
return old_spte;
}
base-commit: f9d48449fbf9aff6cdced4703cdfdfc1d2e49efe
--
> Passing in "bool is_mirror_sp" to __handle_changed_spte() instead?
^ permalink raw reply related
* Re: [PATCH 5/5] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory
From: kernel test robot @ 2026-02-10 18:03 UTC (permalink / raw)
To: Jiri Pirko, dri-devel, linaro-mm-sig, iommu, linux-media
Cc: oe-kbuild-all, sumit.semwal, benjamin.gaignard, Brian.Starkey,
jstultz, tjmercier, christian.koenig, m.szyprowski, robin.murphy,
jgg, leon, sean.anderson, ptesarik, catalin.marinas, aneesh.kumar,
suzuki.poulose, steven.price, thomas.lendacky, john.allen,
ashish.kalra, suravee.suthikulpanit, linux-coco
In-Reply-To: <20260209153809.250835-6-jiri@resnulli.us>
Hi Jiri,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-tip/drm-tip trace/for-next linus/master v6.19]
[cannot apply to next-20260209]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Jiri-Pirko/dma-mapping-avoid-random-addr-value-print-out-on-error-path/20260209-234013
base: https://gitlab.freedesktop.org/drm/misc/kernel.git drm-misc-next
patch link: https://lore.kernel.org/r/20260209153809.250835-6-jiri%40resnulli.us
patch subject: [PATCH 5/5] dma-buf: heaps: system: add an option to allocate explicitly decrypted memory
config: s390-allyesconfig (https://download.01.org/0day-ci/archive/20260211/202602110149.tBUPP0bh-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260211/202602110149.tBUPP0bh-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602110149.tBUPP0bh-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/dma-buf/heaps/system_heap.c: In function 'system_heap_set_page_decrypted':
>> drivers/dma-buf/heaps/system_heap.c:66:15: error: implicit declaration of function 'set_memory_decrypted' [-Wimplicit-function-declaration]
66 | ret = set_memory_decrypted(addr, nr_pages);
| ^~~~~~~~~~~~~~~~~~~~
drivers/dma-buf/heaps/system_heap.c: In function 'system_heap_set_page_encrypted':
>> drivers/dma-buf/heaps/system_heap.c:80:15: error: implicit declaration of function 'set_memory_encrypted' [-Wimplicit-function-declaration]
80 | ret = set_memory_encrypted(addr, nr_pages);
| ^~~~~~~~~~~~~~~~~~~~
vim +/set_memory_decrypted +66 drivers/dma-buf/heaps/system_heap.c
59
60 static int system_heap_set_page_decrypted(struct page *page)
61 {
62 unsigned long addr = (unsigned long)page_address(page);
63 unsigned int nr_pages = 1 << compound_order(page);
64 int ret;
65
> 66 ret = set_memory_decrypted(addr, nr_pages);
67 if (ret)
68 pr_warn_ratelimited("dma-buf system heap: failed to decrypt page at %p\n",
69 page_address(page));
70
71 return ret;
72 }
73
74 static int system_heap_set_page_encrypted(struct page *page)
75 {
76 unsigned long addr = (unsigned long)page_address(page);
77 unsigned int nr_pages = 1 << compound_order(page);
78 int ret;
79
> 80 ret = set_memory_encrypted(addr, nr_pages);
81 if (ret)
82 pr_warn_ratelimited("dma-buf system heap: failed to re-encrypt page at %p, leaking memory\n",
83 page_address(page));
84
85 return ret;
86 }
87
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Dave Hansen @ 2026-02-10 17:44 UTC (permalink / raw)
To: Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini
Cc: linux-kernel, linux-coco, kvm, Kai Huang, Rick Edgecombe,
Yan Zhao, Vishal Annapurve, Ackerley Tng, Sagi Shahar, Binbin Wu,
Xiaoyao Li, Isaku Yamahata
In-Reply-To: <20260129011517.3545883-17-seanjc@google.com>
On 1/28/26 17:14, Sean Christopherson wrote:
> +static void tdx_pamt_put(struct page *page)
> +{
> + u64 pamt_pa_array[MAX_NR_DPAMT_ARGS];
> + atomic_t *pamt_refcount;
> + u64 tdx_status;
> +
> + if (!tdx_supports_dynamic_pamt(&tdx_sysinfo))
> + return;
> +
> + pamt_refcount = tdx_find_pamt_refcount(page_to_pfn(page));
> +
> + scoped_guard(spinlock, &pamt_lock) {
> + /*
> + * If the there are more than 1 references on the pamt page,
> + * don't remove it yet. Just decrement the refcount.
> + */
> + if (atomic_read(pamt_refcount) > 1) {
> + atomic_dec(pamt_refcount);
> + return;
> + }
> +
> + /* Try to remove the pamt page and take the refcount 1->0. */
> + tdx_status = tdh_phymem_pamt_remove(page, pamt_pa_array);
> +
> + /*
> + * Don't free pamt_pa_array as it could hold garbage when
> + * tdh_phymem_pamt_remove() fails. Don't panic/BUG_ON(), as
> + * there is no risk of data corruption, but do yell loudly as
> + * failure indicates a kernel bug, memory is being leaked, and
> + * the dangling PAMT entry may cause future operations to fail.
> + */
> + if (WARN_ON_ONCE(!IS_TDX_SUCCESS(tdx_status)))
> + return;
> +
> + atomic_dec(pamt_refcount);
> + }
> +
> + /*
> + * pamt_pa_array is populated up to tdx_dpamt_entry_pages() by the TDX
> + * module with pages, or remains zero inited. free_pamt_array() can
> + * handle either case. Just pass it unconditionally.
> + */
> + free_pamt_array(pamt_pa_array);
> +}
This looks funky.
Right now, this is:
spin_lock(pamt_lock)
atomic_inc/dec(fine-grained-refcount)
tdcall_blah_blah()
spin_unlock(pamt_lock)
Where it *always* acquires the global lock when DPAMT is supported.
Couldn't we optimize it so that it only acquires it when it has to keep
the refcount stable at zero?
Roughly:
slow_path = atomic_dec_and_lock(fine-grained-refcount,
pamt_lock)
if (!slow_path)
goto out;
// fine-grained-refcount==0 and must stay that way with
// pamt_lock held. Remove the DPAMT pages:
tdh_phymem_pamt_remove(page, pamt_pa_array)
out:
spin_unlock(pamt_lock)
On the acquire side, you do:
fast_path = atomic_inc_not_zero(fine-grained-refcount)
if (fast_path)
return;
// slow path:
spin_lock(pamt_lock)
// Was the race lost with another 0=>1 increment?
if (atomic_read(fine-grained-refcount) > 0)
goto out_inc
tdh_phymem_pamt_add(page, pamt_pa_array)
// Inc after the TDCALL so another thread won't race ahead of us
// and try to use a non-existent PAMT entry
out_inc:
atomic_inc(fine-grained-refcount)
spin_unlock(pamt_lock)
Then, at least only the 0=>1 and 1=>0 transitions need the global lock.
The fast paths only touch the refcount which isn't shared nearly as much
as the global lock.
BTW, this probably still needs to be spin_lock_irq(), not what I wrote
above, but that's not a big deal to add.
I've stared at this for a bit and don't see any holes. Does anyone else
see any?
^ permalink raw reply
* SVSM Development Call February 11, 2026
From: Jörg Rödel @ 2026-02-10 15:56 UTC (permalink / raw)
To: coconut-svsm, linux-coco
Hi,
Here is the call for agenda items for this weeks SVSM development call. Please
send any agenda items you have in mind as a reply to this email or raise them
in the meeting.
We will use the LF Zoom instance. Details of the meeting can be found in our
governance repository at:
https://github.com/coconut-svsm/governance
The link to the COCONUT-SVSM calendar is:
https://zoom-lfx.platform.linuxfoundation.org/meetings/coconut-svsm?view=week
The meeting will be recorded and the recording eventually published.
Regards,
Jörg
^ permalink raw reply
* Re: [PATCH 4/5] dma-buf: heaps: allow heap to specify valid heap flags
From: Jason Gunthorpe @ 2026-02-10 14:54 UTC (permalink / raw)
To: Jiri Pirko
Cc: John Stultz, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, tjmercier,
christian.koenig, m.szyprowski, robin.murphy, leon, sean.anderson,
ptesarik, catalin.marinas, aneesh.kumar, suzuki.poulose,
steven.price, thomas.lendacky, john.allen, ashish.kalra,
suravee.suthikulpanit, linux-coco
In-Reply-To: <y7gvezflidmma7odnut2rmlecsbxahrcwpmoevfnhzjveusuwj@6qxqogin45j3>
On Tue, Feb 10, 2026 at 03:49:02PM +0100, Jiri Pirko wrote:
> Tue, Feb 10, 2026 at 01:43:57PM +0100, jgg@ziepe.ca wrote:
> >On Tue, Feb 10, 2026 at 10:14:08AM +0100, Jiri Pirko wrote:
> >
> >> >I'd advocate that the right design is for userspace to positively
> >> >signal via this flag that it wants/accepts shared memory and without
> >> >the flag shared memory should never be returned.
> >>
> >> We can have the same behaviour with the separate heap, can't we?
> >> Userpace positively signals it wants/accepts the shared memory by
> >> choosing "system_cc_decrypted" heap name.
> >
> >So what do the other heap names do? Always private? Do you ever get
> >heaps that are unknowably private or shared (eg MMIO backed?)
>
> If I understand the code correctly, you may get something like this:
> $ ls /dev/dma_heap/
> default_cma_region
> protected,secure-video
> protected,secure-video-record
> protected,trusted-ui
> system
>
> The "protected*" ones are created by tee. I believe they handle
> memory that is inaccesible to CPU.
If that is the only list of options then maybe just the name will work
Ok.
I *think* CMA and system should be reliably CC private.
The protected ones seem to have their own internal definition, and
probably can't exist on CC VM systems..
Meaning we don't have any shared things leaking through which would be
the point.
Jason
^ permalink raw reply
* Re: [PATCH 4/5] dma-buf: heaps: allow heap to specify valid heap flags
From: Jiri Pirko @ 2026-02-10 14:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: John Stultz, dri-devel, linaro-mm-sig, iommu, linux-media,
sumit.semwal, benjamin.gaignard, Brian.Starkey, tjmercier,
christian.koenig, m.szyprowski, robin.murphy, leon, sean.anderson,
ptesarik, catalin.marinas, aneesh.kumar, suzuki.poulose,
steven.price, thomas.lendacky, john.allen, ashish.kalra,
suravee.suthikulpanit, linux-coco
In-Reply-To: <20260210124357.GD943673@ziepe.ca>
Tue, Feb 10, 2026 at 01:43:57PM +0100, jgg@ziepe.ca wrote:
>On Tue, Feb 10, 2026 at 10:14:08AM +0100, Jiri Pirko wrote:
>
>> >I'd advocate that the right design is for userspace to positively
>> >signal via this flag that it wants/accepts shared memory and without
>> >the flag shared memory should never be returned.
>>
>> We can have the same behaviour with the separate heap, can't we?
>> Userpace positively signals it wants/accepts the shared memory by
>> choosing "system_cc_decrypted" heap name.
>
>So what do the other heap names do? Always private? Do you ever get
>heaps that are unknowably private or shared (eg MMIO backed?)
If I understand the code correctly, you may get something like this:
$ ls /dev/dma_heap/
default_cma_region
protected,secure-video
protected,secure-video-record
protected,trusted-ui
system
The "protected*" ones are created by tee. I believe they handle
memory that is inaccesible to CPU.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox