[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/6] xen/arm: ffa: Preserve secure notification state when polling SPMC


  • To: Jens Wiklander <jens.wiklander@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Thu, 23 Apr 2026 07:37:10 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eOEyCtVTDiTHP6KYDLe6GNrDm6269DXbzWkQrDASJlk=; b=cFB4dHsPZZe64SdOxwFvsCU0GiU8KODoEiO+zLD58Vlaw0Rt75Eh8Ge4zxsJCQ+JISMsPav2oy0Jh8QPVIx4rePVn8ygG5zwCN1lCoytlwk86U+fN3lyNLbEnEL5q+f38sm2RyV2+ARR9cdIETDZOLaHVCM8tx7oe3Zcfa1r2bJhCOnhUBtlIMNYRAyLk5eWi51NPNgIfx232lX/XOXaXMbhWwpilgbTNC+04SSUeYLnMQuMfAFj8u9TxRyhwT/VFOxdcl90PAYXp1aN5sZdrXPvmQC2zWY2t+48yD5GWYMfjf9+iTjV6hesUHg/gkxFG8mMliSrYr0Lw00P5Iy1wA==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eOEyCtVTDiTHP6KYDLe6GNrDm6269DXbzWkQrDASJlk=; b=bDPyYXfRB34jjVm5uBt/f5oMvDhrylQe9/SwtWJmqDG58dpf2vFP5zqyGpJHqAmb0YhZtaquP+Z3whaG6yKL0DjI28NUDXVm8vrLRiGfOSLSaNkE0MrKew6UdmJIO2FJgtg1ao86Jz+jDEfI/FLgzBoYsPGdPUCjMm/6upGgKF9I4m9AmyYSrjyPbeTE6WlDqeIsblVpLkGf4yyMliN5cEqhNI9EhWNR9u5SwebwHvQ+AZ3KL7+2X+UyPZpX7d6BHdp9UrBm9TPQkUotzMVN5bYIPOpnb6Fzv2sriED+ZIb8P5+0YRjaBn0VZ5jSeD8Ht4epLsFDgZnyuFt8c9FmVg==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=fBfbvL8WElHladD60ZhiqEc3tKNTCD7XPHCf11q2AFqb0Ks8J4+e5AARJ4KPU6ym4CTHgpYzdb/gSKfuo+NF1Gwe275wP7qtBmeZwaR+SbPk33bLcYEkQlIzdwsVVvs0NTaDrXrRD+CE4wZV4VLU2PtOzzdNHiDGDrH72ZDjvhJAJYLfpP35VbBIgy56BRNgcRrkQDpN8QkTx1uqYgI+gkq7XquLPLoFQFGY/mSSfWMBKXdTEfcsTerSH4uvlZd+4+SmsSyu9t2P/2nLrE88GkL+5klompKbKonWuLg/WUN/CW5ut0bhh2hAbukf/e5lhbTdhSMVEHVICFpb/QRKYg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dLKBBtUhFRqpf26BFlYL4J3jUdlCUHy/VpvXY54cA8IUQmXLbsidIAGQ5tQqwWpejqgJVAAygT0gcVhsyF6zH6wVNzjfb7yCZmklrfes85/8DcNwkTqlNooP5FuGqCLo3XhoZ2UVH19MfoBFF0aIArDhEsYuQuk4fDKiE419Mz+6QmB3upwiQIPk3sCHddG+Fqi2qowxcxFSQCo0nV7FXwyNso8CISeCm+29piX3r5FO9H8gXXfn/HpcaLjZP8pa28uemmJKu7yjKDmxhbzvzextil8geln4uNY4h9hsc4VZDnZDY1nrMKbVxZoxZOFt3g4NbI6muWaHbdXRqth97Q==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Thu, 23 Apr 2026 07:38:28 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Thread-index: AQHcznAPe0xl1K1kNkahcHWHCVllLLXrDvkAgAE8FwA=
  • Thread-topic: [PATCH 4/6] xen/arm: ffa: Preserve secure notification state when polling SPMC

HI Jens,

> On 22 Apr 2026, at 14:45, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On Fri, Apr 17, 2026 at 3:41 PM Bertrand Marquis
> <bertrand.marquis@xxxxxxx> wrote:
>> 
>> Secure pending state is latched when the SPMC raises the schedule
>> receiver interrupt, but Xen currently clears that latch too aggressively.
>> Guest FFA_NOTIFICATION_INFO_GET consumes secure_pending even though it
>> only reports pending state, and secure FFA_NOTIFICATION_GET only clears
>> the latch when both SP and SPM bitmaps are requested together. This can
>> drop a pending indication before the receiver retrieves secure
>> notifications, or keep INFO_GET reporting stale secure pending state
>> after a successful GET.
>> 
>> Keep secure_pending as a latched indication until secure notifications
>> are actually retrieved. Guest FFA_NOTIFICATION_INFO_GET now reports the
>> latched state without clearing it, while a successful secure
>> FFA_NOTIFICATION_GET clears the latch regardless of which secure bitmap
>> flags were requested. Also protect secure_pending with notif_lock,
>> serialize SPMC INFO_GET polling behind notif_info_lock, and preserve the
>> caller-visible INFO_GET success width.
>> 
>> Functional impact: guest INFO_GET preserves the secure pending
>> indication until secure notifications are retrieved, and successful
>> secure GET clears the guest-visible pending latch.
>> 
>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>> ---
>> xen/arch/arm/tee/ffa_notif.c | 54 +++++++++++++++++++++++-------------
>> 1 file changed, 35 insertions(+), 19 deletions(-)
>> 
>> diff --git a/xen/arch/arm/tee/ffa_notif.c b/xen/arch/arm/tee/ffa_notif.c
>> index 491db3b04df5..fff00ca2baec 100644
>> --- a/xen/arch/arm/tee/ffa_notif.c
>> +++ b/xen/arch/arm/tee/ffa_notif.c
>> @@ -18,6 +18,7 @@
>> 
>> static bool __ro_after_init fw_notif_enabled;
>> static unsigned int __ro_after_init notif_sri_irq;
>> +static DEFINE_SPINLOCK(notif_info_lock);
>> 
>> static void inject_notif_pending(struct domain *d)
>> {
>> @@ -109,6 +110,7 @@ void ffa_handle_notification_info_get(struct 
>> cpu_user_regs *regs)
>> {
>>     struct domain *d = current->domain;
>>     struct ffa_ctx *ctx = d->arch.tee;
>> +    uint32_t fid = get_user_reg(regs, 0);
>>     bool notif_pending;
>> 
>>     if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled )
>> @@ -117,7 +119,10 @@ void ffa_handle_notification_info_get(struct 
>> cpu_user_regs *regs)
>>         return;
>>     }
>> 
>> -    notif_pending = test_and_clear_bool(ctx->notif.secure_pending);
>> +    spin_lock(&ctx->notif.notif_lock);
>> +    notif_pending = ctx->notif.secure_pending;
>> +    spin_unlock(&ctx->notif.notif_lock);
>> +
>>     if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
>>     {
>>         notif_pending |= test_and_clear_bool(ctx->notif.vm_pending);
>> @@ -131,7 +136,9 @@ void ffa_handle_notification_info_get(struct 
>> cpu_user_regs *regs)
>>     if ( notif_pending )
>>     {
>>         /* A pending global notification for the guest */
>> -        ffa_set_regs(regs, FFA_SUCCESS_64, 0,
>> +        ffa_set_regs(regs,
>> +                     smccc_is_conv_64(fid) ? FFA_SUCCESS_64 : 
>> FFA_SUCCESS_32,
>> +                     0,
>>                      1U << FFA_NOTIF_INFO_GET_ID_COUNT_SHIFT, 
>> ffa_get_vm_id(d),
>>                      0, 0, 0, 0);
>>     }
>> @@ -154,6 +161,8 @@ void ffa_handle_notification_get(struct cpu_user_regs 
>> *regs)
>>     uint32_t w5 = 0;
>>     uint32_t w6 = 0;
>>     uint32_t w7 = 0;
>> +    uint32_t secure_flags = flags & ( FFA_NOTIF_FLAG_BITMAP_SP |
>> +                                      FFA_NOTIF_FLAG_BITMAP_SPM );
>> 
>>     if ( !IS_ENABLED(CONFIG_FFA_VM_TO_VM) && !fw_notif_enabled )
>>     {
>> @@ -173,27 +182,16 @@ void ffa_handle_notification_get(struct cpu_user_regs 
>> *regs)
>>         return;
>>     }
>> 
>> -    if ( fw_notif_enabled && (flags & ( FFA_NOTIF_FLAG_BITMAP_SP |
>> -                                        FFA_NOTIF_FLAG_BITMAP_SPM )) )
>> +    if ( fw_notif_enabled && secure_flags )
>>     {
>>         struct arm_smccc_1_2_regs arg = {
>>             .a0 = FFA_NOTIFICATION_GET,
>>             .a1 = recv,
>> -            .a2 = flags & ( FFA_NOTIF_FLAG_BITMAP_SP |
>> -                            FFA_NOTIF_FLAG_BITMAP_SPM ),
>> +            .a2 = secure_flags,
>>         };
>>         struct arm_smccc_1_2_regs resp;
>>         int32_t e;
>> 
>> -        /*
>> -         * Clear secure pending if both FFA_NOTIF_FLAG_BITMAP_SP and
>> -         * FFA_NOTIF_FLAG_BITMAP_SPM are set since secure world can't have
>> -         * any more pending notifications.
>> -         */
>> -        if ( ( flags  & FFA_NOTIF_FLAG_BITMAP_SP ) &&
>> -             ( flags & FFA_NOTIF_FLAG_BITMAP_SPM ) )
>> -            ACCESS_ONCE(ctx->notif.secure_pending) = false;
>> -
>>         arm_smccc_1_2_smc(&arg, &resp);
>>         e = ffa_get_ret_code(&resp);
>>         if ( e )
>> @@ -210,6 +208,10 @@ void ffa_handle_notification_get(struct cpu_user_regs 
>> *regs)
>> 
>>         if ( flags & FFA_NOTIF_FLAG_BITMAP_SPM )
>>             w6 = resp.a6;
>> +
>> +        spin_lock(&ctx->notif.notif_lock);
>> +        ctx->notif.secure_pending = false;
>> +        spin_unlock(&ctx->notif.notif_lock);
>>     }
>> 
>>     if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) )
>> @@ -354,7 +356,10 @@ static void notif_vm_pend_intr(uint16_t vm_id)
>>      * guarantees that the data structure isn't freed while we're accessing
>>      * it.
>>      */
>> -    ACCESS_ONCE(ctx->notif.secure_pending) = true;
>> +    spin_lock(&ctx->notif.notif_lock);
>> +    ctx->notif.secure_pending = true;
>> +    spin_unlock(&ctx->notif.notif_lock);
>> +
>>     inject_notif_pending(d);
>> 
>> out_unlock:
>> @@ -373,11 +378,18 @@ static void notif_sri_action(void *unused)
>>     unsigned int n;
>>     int32_t res;
>> 
>> -    do {
>> +    if ( !fw_notif_enabled )
>> +        return;
> 
> Can this ever happen? Am I missing something?

No in fact it cannot you are right, we will never get
an SRI if firmware notifications are not enabled so
I will remove that.

Cheers
Bertrand


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.