Re: [RFC PATCH v4 8/8] docs: armproposa: l to add separate SCMI node for Xen agent

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

On 23/06/2025 11:02, Julien Grall wrote:
> Hi Stefano and Oleksii,
>
> Let me start with a bit of process. This is discussion is getting 
> fairly difficult to follow.... Can you please trim unrelevant bits 
> when replying?
>
> On 22/06/2025 22:57, Stefano Stabellini wrote:
>> On Thu, 19 Jun 2025, Oleksii Moisieiev wrote:
>>> On 18/06/2025 03:35, Stefano Stabellini wrote:
>>>> On Thu, 12 Jun 2025, Oleksii Moisieiev wrote:
>>>>> On 23/05/2025 23:19, Stefano Stabellini wrote:
>>>>>> On Mon, 19 May 2025, Oleksii Moisieiev wrote:
>>>>>>> From: Grygorii Strashko<grygorii_strashko@xxxxxxxx>
>>> the same (smc-id and shmem) for both the BSP case (no Xen) and the Xen
>>> case (Dom0 domain).
>>>
>>> Meanwhile, the Xen management agent's SCMI node and configuration are
>>> expected to be placed under /chosen.
>>>
>>> This approach ensures that the Host DT remains as unchanged as 
>>> possible.
>>
>> Yes, my main point is that all the device tree information, except for
>> what is under /chosen, should be left unchanged between the BSP case (no
>> Xen) and the Xen case.
>>
>> We have freedom to decide:
>> - the information we put under /chosen and how to interpret it
>> - how to use the information under /firmware/scmi when Xen is present
>>
>>
>>> Currently:
>>>
>>> The Host DT /firmware/scmi node requires modification to point to the
>>> Xen management agent by changing
>>>
>>> the smc-id and shmem values.
>>
>> I don't think we should require changes to /firmware/scmi in the host DT
>> when Xen is present.
>>
>> Often, people don't know when or if Xen is present at the time the
>> Device Tree is generated. So it is best to avoid modification (outside
>> of /chosen).
>
> I am probably missing something. But it looks like TF-A requires to 
> suport multi-agent so Xen can use it. Am I correct?
>
> Furthermore, I can't tell why the multi-agent support is Xen specific. 
> Surely, you may want something similar with other hypervisors? If not, 
> then my next question is why does Xen needs to do things differently?
>
> Cheers,
>

Yes, multi-agent support is required in TF-A for Xen, but this is not 
specific to Xen.


The implementation is based on the scenario described in the last 
paragraph of

section 4.2.1 of DEN0056 [0].


The key points are as follows:

- a Virtual Machine (VM) serves as a non-trusted agent in the

Non-secure Security state.

- a hypervisor acts as a trusted agent in the Non-secure

Security state.

- the hypervisor can configure fine-grained Non-secure resource access 
permissions for

Virtual Machines.

- the hypervisor sets resource access permissions for the agent 
identifier associated with

the channel and assigns the channel to the VM.


Therefore, we can expect other hypervisors to follow this specification.


[0]: https://developer.arm.com/documentation/den0056/latest/