[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 04/10] xen/arm: ffa: Fine granular call support
- To: Julien Grall <julien@xxxxxxx>
- From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
- Date: Thu, 26 Sep 2024 06:39:30 +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=BE/oRQVztHkwyKm4hxB/UyEZ4Ge4eaF9P3R7Ai6Aa3U=; b=HJVJe2H0DmCp5qxYmgtOJrkw2CAmQC48WT82aDW/wN9ex/d1k4wMhJC5x7xRDBbl4xIFiBR+hH5hTAtvwIXRVA1zhmzGClEphjlu75cgWVXloTJ8XYYBruowmswnPEwNh3ZYe6Rz1H64YhdlWXGouEZF9chqTYYqUbjjM8k2nVFmM7FBDDk7EYz7527OKhcaPFiL5z/JdBGQ7bgLt21o8q2hViLSnLa86jcHxpFqU0n/BBv1nihxxXWhv5//gU9mSNU+IpounX0bJD817gEBp89Wb2jN+ORJWB0cem45/bF9cyetAK71D+qF9T3ILfuzoSmX1db6Ndvh2l7+SfUHww==
- 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=BE/oRQVztHkwyKm4hxB/UyEZ4Ge4eaF9P3R7Ai6Aa3U=; b=rK6svKf/JliThm77K/QaBNU8zl1f9DsPiUzkQ70UCkFLFAObRch7vCWaC4t1tx3kTAMxl8TtIdKXgJXsRV31R2ZAbHZftDhAziKUFBJcf5Rul52g9BDYabhyq79HRSYJf76dEobP1TtIXml6bM2awGDDgv717GJS7lWVJ5RLsPg9lf/FHE2OzdoZ5gd3MjBYRMkaH1SzBfAK0la0/jAuAEyu8KkJzh9ZQyMGyRp5j7WjpPyXuaXW4QglAQRC1yET+Oh6Wjmu8heGK4zsfroKLM37Rtw4Wv53F175eM2+12lugbz+Xrez9lV85u6VI+4SBXdU+Trfbrk8rUJ2Aipmtw==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=IHaj5xjbZm9AAd3Eue1pfQjKnqtBIe26e4+tRns/lm1qtPyxpqMcDy8W12Au6bkCd8KQ6ownUwmZoC2U6YoJAYIbhdiaNXWIASY/MMLhb5I0ojYCq8Dw4jDuS5nEfvZzmXdZK7/xLqL0pGOGS4kVkpbkd8yffRJPeRDfFRcsVsVKw7/uV1fnwkQEUd3llpJhkXNaGaPJAep3wy7C2/+WXVoNUaICUSIendU/hk6XYEs2Y/YqK/3hEMCTHRtwDjXq7OB8AEXwUn6idfLecl7lgIn9hxVbAXvkE2Yt3va177VjJTa8FhNra4VBw/3cHY6SM7g6LpHBwGFOeVF/vzhBNA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QNd/ChfkuO5WDLZHDuIKyvL+wrmRzaxNEk4mc0mf72BVtMwcse7aBbDbtUlc5SpkKbuE6dn80FpGV7BaYECihJy94BWNuxZTdKxD7Ha28KR4yWLuMnz06dtg+HjgC0QW4+9ugY3diRlEz/R9emMVilmpvAA8sU8n8tsNKRGaxYVOb+xDLtltCzRccQtv5DjtYo5PwfuIhpR7fPHncfKcIYOButjRqLZ1baYT3vlO4NVqdaidhgdtDRpa6BTYR+B6eH7+oSfJW/R9zwQW0X8eNA4s6gR1OH6pOu0eUUksRPM/KeDgQJi+bUf4h1C6nfPCDZovPn3jubY0FmArLzQIrA==
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: Jens Wiklander <jens.wiklander@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>
- Delivery-date: Thu, 26 Sep 2024 06:40:03 +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: AQHbCo5KX65uygb9tUuG+eWGxSrgRrJjyouAgAGIQ4CAA2/dAIAA5doA
- Thread-topic: [PATCH 04/10] xen/arm: ffa: Fine granular call support
Hi Julien,
I will answer after to your previous comments but I wanted to jump in on this
subject first.
> On 25 Sep 2024, at 18:56, Julien Grall <julien@xxxxxxx> wrote:
>
>
>
> On 23/09/2024 13:27, Jens Wiklander wrote:
>> Hi,
>
> Hi,
>
>> On Sun, Sep 22, 2024 at 3:04 PM Julien Grall <julien@xxxxxxx> wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 19/09/2024 14:19, Bertrand Marquis wrote:
>>>> Create a bitmap to store which feature is supported or not by the
>>>> firmware and use it to filter which calls done to the firmware.
>>>>
>>>> With this enabled. allow FF-A support to be activated for guest even if
>>>
>>> Typo: s/./,/ I think.
>>>
>>>> the firmware does not support it.
>>>
>>> Can you explain why you want to do this?
>>>
>>> The TEE mediator was designed to interpose with the HW. Without the HW
>>> it doesn't entirely make sense to try to use it.
>>>
>>> It would also not work if the host system is using OP-TEE and expose to
>>> some VM FF-A. So it feels that the mediator may not be the right place
>>> to handle this case.
>> That's a good point, but all the FF-A handling should be in the same
>> module since there's bound to be code and state to share. The problem
>> is that FF-A tries to be a TEE mediator while it's about to become
>> more than that. We can work around it by probing the OP-TEE mediator
>> first, but it's adding another exception or special case. Would it
>> make sense to move the FF-A mediator out of the TEE mediator framework
>> and establish it separately?
>
> I don't particularly want to have the FF-A mediator out of the TEE mediator.
> At the moment, it is unclear to me how much of the SMC handling code can
> really be shared between a domain talking with the host firmware and an
> emulated version. Are we just going to end up to have "if firmware then to
> this else do that"?
We will need to have a debate on how to handle Optee Mediator versus FF-A once
we have FF-A support between VM.
In this case we could have cases where the firmware and secure world does not
support FF-A and optee is using the current protocol but someone wants to use
FF-A between VMs. My guts feeling right now is that we could (and probably
should) not allow this use case as it would be realistic to say that a firmware
support FF-A at some point would not support the old optee protocol.
At the status of this patch (and i do not plan to push VM to VM support in
anything else than an RFC in the next weeks), I think FF-A should stay as a TEE
mediator and I will revert the change enabling FF-A support in Xen when the
firmware does not support it as we do not need that before VM to VM FF-A
support is added.
Now even with that comes a question: What to do if the firmware supports FF-A
but secure world has optee but using the old protocol.
Should we probe optee first and FF-A second ?
Cheers
Bertrand
>
> Cheers,
>
> --
> Julien Grall
|