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

Re: [PATCH 01/10] xen/arm: ffa: Rework firmware discovery


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 24 Sep 2024 08:26:36 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.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=WALSn8EshjMyNCAnuDZphwE72NLda7kXeHIAbGuXqw0=; b=i+KLAw5Sqj0Mw3ws3pnfnM2G2Sx8lpQstBlw4CE50ZE/3tCmTr0nqOJfL9eZq0r47Z41BKLCXL267RJiJM6Aqmatx3TNw/ycdWrsoqfsSE89ByJ8PuaA1QYOnI/9PKjhuCnDHNpcCzm2LWwqZxvZC7aih1tgmOXNtFIk6XRgoQ2zHKfKdU7pkn3LaBEKyTa/6du/U8ZX5KFfwDfV3Lr/n6c8xI/NYpkoGS0UmaLTy+azIr7ba75fUR9rwShqWSZQDAIjb8GK3CApUIFINucm0VWR4YekhWjYuiTu9pgs128JiZJ/b1yUFDWK7ScX00z73x0KReLGOqy9G6XO9WzyBg==
  • 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=WALSn8EshjMyNCAnuDZphwE72NLda7kXeHIAbGuXqw0=; b=MV2hLdIvImrsGQHMdF+EtM5TA9lNMhyTG7tpABnSE9zan4A331nGdMdEdwyUopR2EEi4VzB0D6mR6rGzhEAIq12F1AZEWgjdgYpMsW9I7fkGOvAfWQAjg73oetxjur/YDQ/DEaNBP8Lk6DBuTod7wQ8jvDAgnDMCf+rSqNb+MRxv8d51DQUT7EJU4HMsS1NetR3KkzsB3bHQyk46uqJ0yN9Sc9XvR2ZWxF+E+or4DvJz1Fng2kryERGDhMZSqlYX5WWKNeQZZyRfWsfslFZBj/tbvfvny4GVv/1EY3xnfKcCWuS8rRr5awjuymJOMSx3HC53GRvWsiL0vxWgBEoj3Q==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=JWyT73TgdA3ysDOwXeYSA1Dc5vMgW9FXZy+XJoS+9P9wRDGeA0MwxrTUlTPgA9vI7uCKBJeT3SI/SRWnKDwjvUw7ROvQhdmu0AwTaB5klohQp1LSH87p1mKoAT70Aq81wClPTJsfsxurRR8WYkcmQJyoKA3HICR02q0fd8rAsW5pQm5f7Jk+eTS9joPOY4DCCb03+rOfkXFGbIlXI+Ali1NALHab7q4JcgZkfoZcu1hOa6O+1SW5DqwyLUF26QSFvJIRMn65QvqHHbnaFl6yoa+5o8TzMuUVNQiz/F2vJ2M3Bo59C9cTI+45yKGYl3oDtTkip3hhqKZEmeK2JzOLXA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qYW1MvKOZgZQMyHmf8SWu0qsuyeYgkdQLcmEkgOqs2crK7SHj10+9Zq/f4f9XDWHivZqdF0PlejsXfkzRrlQFvOyKBO6uIX+twZcsJiCtWp2qyny53AAqoCTZIxu3QEmdMZLupXF+kPeLZEYEX+RuAr3V2X6tNIC65MVUNel0RZjHlv5ex980cjA/jqMYC2d/QCHG5jm9L40SBxqT3DX9SmuebY3UWxLnAf1i1Y+sqs1lvg+fT4v86+WTJf2ouFy8YnNuT0SVx+2Gc/HhbWC2Dm1JuzKg6AFyX3qprDVYjmPQUVKHq8njYYu8NSuw3Lr9gsxn7DM5ZBRt+3jWe2WBA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
  • Delivery-date: Tue, 24 Sep 2024 08:27:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHbCo5BamB/XsNnokyTz9637lD4+bJjhr0AgAMbCwA=
  • Thread-topic: [PATCH 01/10] xen/arm: ffa: Rework firmware discovery

Hi Julien,

> On 22 Sep 2024, at 11:00, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On 19/09/2024 14:19, Bertrand Marquis wrote:
>> Rework firmware discovery during probe:
>> - move prints into the probe
>> - rename ffa_version to ffa_fw_version as the variable identifies the
>>   version of the firmware and not the one we support
>> - add error prints when allocation fail during probe
>> No functional changes.
>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>> ---
>>  xen/arch/arm/tee/ffa.c | 52 +++++++++++++++++++++++++-----------------
>>  1 file changed, 31 insertions(+), 21 deletions(-)
>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>> index 022089278e1c..7c84aa6aa43d 100644
>> --- a/xen/arch/arm/tee/ffa.c
>> +++ b/xen/arch/arm/tee/ffa.c
>> @@ -71,8 +71,8 @@
>>    #include "ffa_private.h"
>>  -/* Negotiated FF-A version to use with the SPMC */
>> -static uint32_t __ro_after_init ffa_version;
>> +/* Negotiated FF-A version to use with the SPMC, 0 if not there or 
>> supported */
>> +static uint32_t __ro_after_init ffa_fw_version;
>>      /*
>> @@ -105,10 +105,7 @@ static bool ffa_get_version(uint32_t *vers)
>>        arm_smccc_1_2_smc(&arg, &resp);
>>      if ( resp.a0 == FFA_RET_NOT_SUPPORTED )
>> -    {
>> -        gprintk(XENLOG_ERR, "ffa: FFA_VERSION returned not supported\n");
>>          return false;
>> -    }
>>        *vers = resp.a0;
>>  @@ -372,7 +369,7 @@ static int ffa_domain_init(struct domain *d)
>>      struct ffa_ctx *ctx;
>>      int ret;
>>  -    if ( !ffa_version )
>> +    if ( !ffa_fw_version )
>>          return -ENODEV;
>>       /*
>>        * We can't use that last possible domain ID or ffa_get_vm_id() would
>> @@ -505,6 +502,9 @@ static bool ffa_probe(void)
>>       */
>>      BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
>>  +    printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
>> +           FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
> > +>       /*
>>       * psci_init_smccc() updates this value with what's reported by EL-3
>>       * or secure world.
>> @@ -514,25 +514,21 @@ static bool ffa_probe(void)
>>          printk(XENLOG_ERR
>>                 "ffa: unsupported SMCCC version %#x (need at least %#x)\n",
>>                 smccc_ver, ARM_SMCCC_VERSION_1_2);
>> -        return false;
>> +        goto err_no_fw;
>>      }
>>        if ( !ffa_get_version(&vers) )
>> -        return false;
>> +    {
>> +        gprintk(XENLOG_ERR, "ffa: FFA_VERSION returned not supported\n");
> 
> This error message relies on the implementation of ffa_get_version(). It made 
> sense in the previous placement, but here, it seems a little bit odd. So if 
> you want to move the error message, then I think it should be reworded to be 
> more generic.
> 
> Maybe: "Cannot retrieve the FFA version".

Ack

> 
>> +        goto err_no_fw;
>> +    }
>>        if ( vers < FFA_MIN_SPMC_VERSION || vers > FFA_MY_VERSION )
>>      {
>>          printk(XENLOG_ERR "ffa: Incompatible version %#x found\n", vers);
>> -        return false;
>> +        goto err_no_fw;
>>      }
>>  -    major_vers = (vers >> FFA_VERSION_MAJOR_SHIFT) & 
>> FFA_VERSION_MAJOR_MASK;
>> -    minor_vers = vers & FFA_VERSION_MINOR_MASK;
>> -    printk(XENLOG_INFO "ARM FF-A Mediator version %u.%u\n",
>> -           FFA_MY_VERSION_MAJOR, FFA_MY_VERSION_MINOR);
> 
> I kind of understand why we are moving the Medatior version early but...
> 
>> -    printk(XENLOG_INFO "ARM FF-A Firmware version %u.%u\n",
>> -           major_vers, minor_vers);
> 
> ... I am not sure why we would move this print later. Wouldn't this be useful 
> to know if there is a missing feature?

True I will move it back up.

>> -
>>      /*
>>       * At the moment domains must support the same features used by Xen.
>>       * TODO: Rework the code to allow domain to use a subset of the
>> @@ -546,12 +542,24 @@ static bool ffa_probe(void)
>>           !check_mandatory_feature(FFA_MEM_SHARE_32) ||
>>           !check_mandatory_feature(FFA_MEM_RECLAIM) ||
>>           !check_mandatory_feature(FFA_MSG_SEND_DIRECT_REQ_32) )
>> -        return false;
>> +    {
>> +        printk(XENLOG_ERR "ffa: Mandatory feature not supported by fw\n");
>> +        goto err_no_fw;
>> +    }
>>  -    if ( !ffa_rxtx_init() )
>> -        return false;
>> +    major_vers = (vers >> FFA_VERSION_MAJOR_SHIFT)
>> +                 & FFA_VERSION_MAJOR_MASK;
>> +    minor_vers = vers & FFA_VERSION_MINOR_MASK;
>> +    printk(XENLOG_INFO "ARM FF-A Firmware version %u.%u\n",
>> +           major_vers, minor_vers);
>> +
>> +    ffa_fw_version = vers;
>>  -    ffa_version = vers;
>> +    if ( !ffa_rxtx_init() )
>> +    {
>> +        printk(XENLOG_ERR "ffa: Error during RXTX buffer init\n");
>> +        goto err_no_fw;
>> +    }
>>        if ( !ffa_partinfo_init() )
>>          goto err_rxtx_destroy;
>> @@ -564,7 +572,9 @@ static bool ffa_probe(void)
>>    err_rxtx_destroy:
>>      ffa_rxtx_destroy();
>> -    ffa_version = 0;
>> +err_no_fw:
>> +    ffa_fw_version = 0;
>> +    printk(XENLOG_INFO "ARM FF-A No firmware support\n");
> 
> I am guessing if we are trying to probe FFA, then most likely the user 
> expected to use it. So shouldn't this be a XENLOG_WARN?

Ack.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall





 


Rackspace

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