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

Re: [PATCH v1 03/12] xen/arm: ffa: Fix is_64bit init


  • To: Jens Wiklander <jens.wiklander@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 9 Dec 2025 10:10:27 +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=et+xaRsON/DM4yFtAoptGyCY3LG1XOk2ch8yrqMsHrQ=; b=LkmZQRDEh0iKAQ4/bH5AjsfFWPJ+TxSPh+SzZrqY8Xqa9RQPQ5wwYqgmlr3ddtnU9hdD/OBN0zCQT06JItGbVRlruNUd4uFQFna03GGm7an8nF4PPwy2eUDiQZ+GOT5IV/MZodPRHp+UyS7vSVbTsa3W1nah0Zt1/BTPCcvQ6gpDtLBsjrMDJyKUOdRlqa3YzS57q7O1BmWxXOxps+BwADQGF2MABp+OuOeW3moF/piAfoR0LHiQc8K1oAbdLyMkQq5+cvBKBwS5tBzdCKw9Q310HJnOnmEgXLLV0p0eCD7vtbMvzfkV/FiuS/O+98xsfkZkPDnL77lD2HF0DUM62Q==
  • 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=et+xaRsON/DM4yFtAoptGyCY3LG1XOk2ch8yrqMsHrQ=; b=GWIC4k174aKm3Jtpd3ip92Dne/6C9W8a3BN5kANWLQ+O8prHMSZRMndjSAgzpvagnUaaAhgDg6lzEBeNEhecKp8w3rjNNoAab6xJAFI+29Ex1O73xUUzUm4qDSgj9Tq+FYdl25skNtyQCQDIh9a9tqqD/5Pcf7eSaXNAWqMqa2XMkq6Ym9dWNFwiCD5Y+W80SI1/U/NYvVyuaHHeWgxKfiiXkoiYzq+9+IE5JpB57ZglvTH0PJjs/4JWQ78H0AXHmoVFvendPmKjYs/UW1wn86daVJ0tYRSgulW7WKL4ZqVnLaeWjEhtGSIIsdo1+UGkEZkV1yh4vJ7kH+JJK4NoOw==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=ChRjUdj9IsJFySsK/IPpFnAisGWBwXnHoOkagBLe1nBSwAfG5xhLY5YoTuJNZ14wL584kuCW2deEpUF37mpywOrWm+G16iO62UNDsJ3PuLnVVAXSKVreQLHutDVSiJdp5gXR3+xxil4yomzHYSy9j6qTCpkyDDUQXygBYWVsocea3lBbooSrqcHqSyarLpntlRkp3UZSmisib+cq6xRyRpaoEgwX2J50mhzNEEcGj3CKfQXlEfWTIDMaA7Fh/QByTxUQ0EOxYKCgqOIAkJMxCpaLlehICJcEdtcxLHqLuzLzcQKtiTEaffxfErjIcWRrJ9mx4SMmoGj7SLmme8Op7Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YB20o/HhlZCpzzZ5Az9QAA3aIoZj7PpRBJ5urnEg1/wi7tHlWQt8pUawKi35LorBtGDlzTtCm/vzCG7pAuhEvNgr0oKrCM//WoInu4ANIJyY2rHx2xMNVKuL5oLz/SEfZVPY7Jf1CVozZQbz4Hp3hlbDXEn0vW5HFCDRVmDdij/rQ7rlYGI/wOfqMDChbu2sDO+1fmvKmMYYgfDaL8gHaZ0vUxO2xZZoOFdeyH24RBMEy20Li2s1alo1Zdp7t5Q2GBOppdAiOka/7mWRnoOyO9oK/R1hyWtinFZJVdmDgI0rH5C+106BoFhdQe6tQAgDTjlHoX6Yq1HamgXcYr0mtw==
  • 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: Tue, 09 Dec 2025 10:11:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Thread-index: AQHcZdM4PJInZ7Ib+k6qqA68hny4k7UZGx8AgAABQgA=
  • Thread-topic: [PATCH v1 03/12] xen/arm: ffa: Fix is_64bit init

Hi Jens,

> On 9 Dec 2025, at 10:05, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On Fri, Dec 5, 2025 at 11:37 AM Bertrand Marquis
> <bertrand.marquis@xxxxxxx> wrote:
>> 
>> is_64bit_domain(d) is not set during domain_init as the domain field is
>> only set when loading the domain image which is done after executing
>> domain_init.
>> 
>> Fix the implementation to set is_64bit when version gets negotiated.
>> is_64bit is only used during partition_info_get once a domain is added
>> in the list of domains having ffa support. It must only be accessed when
>> the rwlock is taken (which is the case).
>> 
>> is_64bit must not be used without the rwlock taken and other places in
>> the code needing to test 64bit support of the current domain will have
>> to use calls to is_64bit_domain instead of the field from now on.
>> 
>> Fixes: 09a201605f99 ("xen/arm: ffa: Introduce VM to VM support")
>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>> ---
>> Changes in v1:
>> - patch introduced
>> ---
>> xen/arch/arm/tee/ffa.c         | 9 ++++++++-
>> xen/arch/arm/tee/ffa_private.h | 5 +++++
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>> 
>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>> index aadd6c21e7f2..0f6f837378cc 100644
>> --- a/xen/arch/arm/tee/ffa.c
>> +++ b/xen/arch/arm/tee/ffa.c
>> @@ -180,6 +180,14 @@ static bool ffa_negotiate_version(struct cpu_user_regs 
>> *regs)
>>             goto out_handled;
>>         }
>> 
>> +        /*
>> +         * We cannot set is_64bit during domain init because the field is 
>> not
>> +         * yet initialized.
>> +         * This field is only used during partinfo_get with the rwlock taken
>> +         * so there is no ordering issue with guest_vers.
>> +         */
>> +        ctx->is_64bit = is_64bit_domain(d);
> 
> This should only be assigned under the rwlock. But do we need the
> is_64bit field at all? Why can't we always use is_64bit_domain()
> instead?

As we take it after when needed, setting it here should be ok but i can move 
this
inside the rwlock section to be more coherent.

The field is needed when creating the list of partitions. To use 
is_64bit_domain, I
would to get access to the foreign domain description which i try to prevent to 
not
create a way for a guest to block other guests by doing partinfo_get. This is 
why
i store the information i need for foreign guests in the ctx instead of using 
RCU
to get access to the domain descriptor.

Cheers
Bertrand

> 
> Cheers,
> Jens
> 
>> +
>>         /*
>>          * A successful FFA_VERSION call does not freeze negotiation. Guests
>>          * are allowed to issue multiple FFA_VERSION attempts (e.g. probing
>> @@ -433,7 +441,6 @@ static int ffa_domain_init(struct domain *d)
>> 
>>     ctx->ffa_id = ffa_get_vm_id(d);
>>     ctx->num_vcpus = d->max_vcpus;
>> -    ctx->is_64bit = is_64bit_domain(d);
>> 
>>     /*
>>      * ffa_domain_teardown() will be called if ffa_domain_init() returns an
>> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
>> index 4e4ac7fd7bc4..2daa4589a930 100644
>> --- a/xen/arch/arm/tee/ffa_private.h
>> +++ b/xen/arch/arm/tee/ffa_private.h
>> @@ -344,6 +344,11 @@ struct ffa_ctx {
>>     /* FF-A Endpoint ID */
>>     uint16_t ffa_id;
>>     uint16_t num_vcpus;
>> +    /*
>> +     * Must only be accessed with the ffa_ctx_list_rwlock taken as it set
>> +     * when guest_vers is set and other accesses could see a partially set
>> +     * value.
>> +     */
>>     bool is_64bit;
>> 
>>     /*
>> --
>> 2.51.2



 


Rackspace

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