Re: [PATCH v3] docs/misra: add R21.6 R21.9 R21.10 R21.14 R21.15 R21.16

[Bertrand Marquis]

Hi Stefano,


> On 26 Apr 2024, at 23:36, Stefano Stabellini  wrote:
> 
> Signed-off-by: Stefano Stabellini 

You might want to answer to Andrew on the footnote and agree or not on his way 
to fix.

Appart from that:
Acked-by: Bertrand Marquis 

Cheers
Bertrand


> ---
> 
> Changes in v3:
> - add explanation in footnote
> - remove comment from 21.14, 21.15, 21.16
> 
> docs/misra/rules.rst | 42 ++
> 1 file changed, 42 insertions(+)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index b7b447e152..5ba7394f05 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -652,12 +652,48 @@ maintainers if you want to suggest a change.
>declared
>  - See comment for Rule 21.1
> 
> +   * - `Rule 21.6 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_06.c>`_
> + - Required
> + - The Standard Library input/output routines shall not be used
> + - Xen doesn't provide, use, or link against a Standard Library [1]_
> +
> +   * - `Rule 21.9 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_09.c>`_
> + - Required
> + - The library functions bsearch and qsort of  shall not be 
> used
> + - Xen doesn't provide, use, or link against a Standard Library [1]_
> +
> +   * - `Rule 21.10 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_10.c>`_
> + - Required
> + - The Standard Library time and date routines shall not be used
> + - Xen doesn't provide, use, or link against a Standard Library [1]_
> +
>* - `Rule 21.13 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_13.c>`_
>  - Mandatory
>  - Any value passed to a function in  shall be representable as 
> an
>unsigned char or be the value EOF
>  -
> 
> +   * - `Rule 21.14 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_14.c>`_
> + - Required
> + - The Standard Library function memcmp shall not be used to compare
> +   null terminated strings
> + -
> +
> +   * - `Rule 21.15 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_15.c>`_
> + - Required
> + - The pointer arguments to the Standard Library functions memcpy,
> +   memmove and memcmp shall be pointers to qualified or unqualified
> +   versions of compatible types
> + -
> +
> +   * - `Rule 21.16 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_16.c>`_
> + - Required
> + - The pointer arguments to the Standard Library function memcmp
> +   shall point to either a pointer type, an essentially signed type,
> +   an essentially unsigned type, an essentially Boolean type or an
> +   essentially enum type
> + - void* arguments are allowed
> +
>* - `Rule 21.17 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_17.c>`_
>  - Mandatory
>  - Use of the string handling functions from  shall not result 
> in
> @@ -712,3 +748,9 @@ maintainers if you want to suggest a change.
>  - The value of a pointer to a FILE shall not be used after the associated
>stream has been closed
>  -
> +
> +
> +.. [1] Xen implements itself a few functions with names that match the
> +   corresponding function names of the Standard Library for developers'
> +   convenience. These functions are part of the Xen code and subject to
> +   analysis.
> -- 
> 2.25.1
> 

Re: [XEN PATCH v3 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Julien,

> On 26 Apr 2024, at 21:07, Julien Grall  wrote:
> 
> Hi Jens,
> 
> On 26/04/2024 09:47, Jens Wiklander wrote:
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index d7306aa64d50..5224898265a5 100644
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -155,7 +155,7 @@ void __init init_IRQ(void)
>>  {
>>  /* SGIs are always edge-triggered */
>>  if ( irq < NR_GIC_SGI )
>> -local_irqs_type[irq] = DT_IRQ_TYPE_EDGE_RISING;
>> +local_irqs_type[irq] = IRQ_TYPE_EDGE_RISING;
> 
> This changes seems unrelated to this patch. This wants to be separate (if you 
> actually intended to change it).
> 
>>  else
>>  local_irqs_type[irq] = IRQ_TYPE_INVALID;
>>  }
>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
>> index f0112a2f922d..7c0f46f7f446 100644
>> --- a/xen/arch/arm/tee/Makefile
>> +++ b/xen/arch/arm/tee/Makefile
>> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
>>  obj-$(CONFIG_FFA) += ffa_shm.o
>>  obj-$(CONFIG_FFA) += ffa_partinfo.o
>>  obj-$(CONFIG_FFA) += ffa_rxtx.o
>> +obj-$(CONFIG_FFA) += ffa_notif.o
>>  obj-y += tee.o
>>  obj-$(CONFIG_OPTEE) += optee.o
>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>> index 5209612963e1..912e905a27bd 100644
>> --- a/xen/arch/arm/tee/ffa.c
>> +++ b/xen/arch/arm/tee/ffa.c
>> @@ -39,6 +39,9 @@
>>   *   - at most 32 shared memory regions per guest
>>   * o FFA_MSG_SEND_DIRECT_REQ:
>>   *   - only supported from a VM to an SP
>> + * o FFA_NOTIFICATION_*:
>> + *   - only supports global notifications, that is, per vCPU notifications
>> + * are not supported
>>   *
>>   * There are some large locked sections with ffa_tx_buffer_lock and
>>   * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
>> @@ -194,6 +197,8 @@ out:
>>static void handle_features(struct cpu_user_regs *regs)
>>  {
>> +struct domain *d = current->domain;
>> +struct ffa_ctx *ctx = d->arch.tee;
>>  uint32_t a1 = get_user_reg(regs, 1);
>>  unsigned int n;
>>  @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
>>  BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
>>  ffa_set_regs_success(regs, 0, 0);
>>  break;
>> +case FFA_FEATURE_NOTIF_PEND_INTR:
>> +if ( ctx->notif.enabled )
>> +ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0);
>> +else
>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>> +break;
>> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
>> +if ( ctx->notif.enabled )
>> +ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0);
>> +else
>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>> +break;
>> +
>> +case FFA_NOTIFICATION_BIND:
>> +case FFA_NOTIFICATION_UNBIND:
>> +case FFA_NOTIFICATION_GET:
>> +case FFA_NOTIFICATION_SET:
>> +case FFA_NOTIFICATION_INFO_GET_32:
>> +case FFA_NOTIFICATION_INFO_GET_64:
>> +if ( ctx->notif.enabled )
>> +ffa_set_regs_success(regs, 0, 0);
>> +else
>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>> +break;
>>  default:
>>  ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>  break;
>> @@ -305,6 +334,22 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
>>   get_user_reg(regs, 1)),
>> get_user_reg(regs, 3));
>>  break;
>> +case FFA_NOTIFICATION_BIND:
>> +e = ffa_handle_notification_bind(regs);
>> +break;
>> +case FFA_NOTIFICATION_UNBIND:
>> +e = ffa_handle_notification_unbind(regs);
>> +break;
>> +case FFA_NOTIFICATION_INFO_GET_32:
>> +case FFA_NOTIFICATION_INFO_GET_64:
>> +ffa_handle_notification_info_get(regs);
>> +return true;
>> +case FFA_NOTIFICATION_GET:
>> +ffa_handle_notification_get(regs);
>> +return true;
>> +case FFA_NOTIFICATION_SET:
>> +e = ffa_handle_notification_set(regs);
>> +break;
>>default:
>>  gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
>> @@ -322,6 +367,7 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
>>  static int ffa_domain_init(struct domain *d)
>>  {
>>  struct ffa_ctx *ctx;
>> +int ret;
>>if ( !ffa_version )
>>  return -ENODEV;
>> @@ -345,10 +391,11 @@ static int ffa_domain_init(struct domain *d)
>>   * error, so no need for cleanup in this function.
>>   */
>>  -if ( !ffa_partinfo_domain_init(d) )
>> -return -EIO;
>> +ret = ffa_partinfo_domain_init(d);
>> +if ( ret )
>> +return ret;
>>  -return 0;
>> +return ffa_notif_domain_init(d);
>>  }
>>static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool 
>> first_time)
>> @@ -423,6 +470,7 @@ static int ffa_domain_teardown(struct domain *d)
>>  return 

Re: [XEN PATCH v3 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 26 Apr 2024, at 15:02, Jens Wiklander  wrote:
> 
> On Fri, Apr 26, 2024 at 2:41 PM Bertrand Marquis
>  wrote:
>> 
>> Hi Jens,
>> 
>>> On 26 Apr 2024, at 14:32, Jens Wiklander  wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
>>>  wrote:
>>>> 
>>>> Hi Jens,
>>>> 
>>>>> On 26 Apr 2024, at 14:11, Jens Wiklander  
>>>>> wrote:
>>>>> 
>>>>> Hi Bertrand,
>>>>> 
>>>>> On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
>>>>>  wrote:
>>>>>> 
>>>>>> Hi Jens,
>>>>>> 
>>>>>>> On 26 Apr 2024, at 10:47, Jens Wiklander  
>>>>>>> wrote:
>>>>>>> 
>>> [...]
>>>>>>> +struct notif_irq_info {
>>>>>>> +unsigned int irq;
>>>>>>> +int ret;
>>>>>>> +struct irqaction *action;
>>>>>>> +};
>>>>>>> +
>>>>>>> +static void notif_irq_enable(void *info)
>>>>>>> +{
>>>>>>> +struct notif_irq_info *irq_info = info;
>>>>>>> +
>>>>>>> +irq_info->ret = setup_irq(irq_info->irq, 0, irq_info->action);
>>>>>>> +if ( irq_info->ret )
>>>>>>> +printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n",
>>>>>>> +   irq_info->irq, irq_info->ret);
>>>>>>> +}
>>>>>>> +
>>>>>>> +void ffa_notif_init(void)
>>>>>>> +{
>>>>>>> +const struct arm_smccc_1_2_regs arg = {
>>>>>>> +.a0 = FFA_FEATURES,
>>>>>>> +.a1 = FFA_FEATURE_SCHEDULE_RECV_INTR,
>>>>>>> +};
>>>>>>> +struct notif_irq_info irq_info = { };
>>>>>>> +struct arm_smccc_1_2_regs resp;
>>>>>>> +unsigned int cpu;
>>>>>>> +
>>>>>>> +arm_smccc_1_2_smc(, );
>>>>>>> +if ( resp.a0 != FFA_SUCCESS_32 )
>>>>>>> +return;
>>>>>>> +
>>>>>>> +irq_info.irq = resp.a2;
>>>>>>> +if ( irq_info.irq < GIC_SGI_STATIC_MAX || irq_info.irq >= 
>>>>>>> NR_GIC_SGI )
>>>>>>> +{
>>>>>>> +printk(XENLOG_ERR "ffa: notification initialization failed: 
>>>>>>> conflicting SGI %u\n",
>>>>>>> +   irq_info.irq);
>>>>>>> +return;
>>>>>>> +}
>>>>>>> +
>>>>>>> +/*
>>>>>>> + * SGIs are per-CPU so we must enable the IRQ on each CPU. We use 
>>>>>>> an
>>>>>>> + * IPI to call notif_irq_enable() on each CPU including the current
>>>>>>> + * CPU. The struct irqaction is preallocated since we can't 
>>>>>>> allocate
>>>>>>> + * memory while in interrupt context.
>>>>>>> + */
>>>>>>> +for_each_online_cpu(cpu)
>>>>>>> +{
>>>>>>> +irq_info.action = xmalloc(struct irqaction);
>>>>>> 
>>>>>> You allocate one action per cpu but you have only one action pointer in 
>>>>>> your structure
>>>>>> which means you will overload the previously allocated one and lose 
>>>>>> track.
>>>>>> 
>>>>>> You should have a table of actions in your structure instead unless one 
>>>>>> action is
>>>>>> enough and can be reused on all cpus and in this case you should move 
>>>>>> out of
>>>>>> your loop the allocation part.
>>>>> 
>>>>> That shouldn't be needed because this is done in sequence only one CPU
>>>>> at a time.
>>>> 
>>>> Sorry i do not understand here.
>>>> You have a loop over each online cpu and on each loop you are assigning
>>>> irq_info.action with a newly allocated struct irqaction so you are in 
>>>> practice
>>>> overloading on cpu 2 the action that was allocated for cpu 1.
>>>> 
>>>> What do you mean by sequence here ?
>>>> 
>>> 
>>> My understanding is that for_each_online_cpu(cpu) loops over each cpu,
>>> one at a time. The call
>>> on_selected_cpus(cpumask_of(cpu), notif_irq_enable, _info, 1);
>>> returns after notif_irq_enable() has returned on the CPU in question
>>> thanks to the "1" (wait) parameter. So once it has returned _info
>>> isn't used by the other CPU any longer and we can assign a new value
>>> to irq_info.action.
>> 
>> Right so you loose track of what was assigned so you are not able to
>> free it.
>> If that is wanted then why saving this in irq.action as you will only have
>> there the one allocated for the last online cpu.
> 
> Wouldn't release_irq() free it? An error here is unlikely, but we may
> be left with a few installed struct irqaction if it occurs. I can add
> a more elaborate error path if it's worth the added complexity.

I think just add a comment saying that the irqaction will be freed
upon release_irq so we do not keep a reference to it or something
like that and this will be ok.

The code is in fact a bit misleading because the irqaction is used
inside the function called on other cores through the IPI and there
you actually pass the action. Your structure is only there to transport
the information for the IPI handler.
So please add a comment on top of the notif_irq_info to say that
this structure is used to pass information to and back the notif_irq_enable
executed using an IPI on other cores.

Cheers
Bertrand


> 
> Thanks,
> Jens

Re: [XEN PATCH v3 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 26 Apr 2024, at 14:32, Jens Wiklander  wrote:
> 
> Hi Bertrand,
> 
> On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
>  wrote:
>> 
>> Hi Jens,
>> 
>>> On 26 Apr 2024, at 14:11, Jens Wiklander  wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
>>>  wrote:
>>>> 
>>>> Hi Jens,
>>>> 
>>>>> On 26 Apr 2024, at 10:47, Jens Wiklander  
>>>>> wrote:
>>>>> 
> [...]
>>>>> +struct notif_irq_info {
>>>>> +unsigned int irq;
>>>>> +int ret;
>>>>> +struct irqaction *action;
>>>>> +};
>>>>> +
>>>>> +static void notif_irq_enable(void *info)
>>>>> +{
>>>>> +struct notif_irq_info *irq_info = info;
>>>>> +
>>>>> +irq_info->ret = setup_irq(irq_info->irq, 0, irq_info->action);
>>>>> +if ( irq_info->ret )
>>>>> +printk(XENLOG_ERR "ffa: request_irq irq %u failed: error %d\n",
>>>>> +   irq_info->irq, irq_info->ret);
>>>>> +}
>>>>> +
>>>>> +void ffa_notif_init(void)
>>>>> +{
>>>>> +const struct arm_smccc_1_2_regs arg = {
>>>>> +.a0 = FFA_FEATURES,
>>>>> +.a1 = FFA_FEATURE_SCHEDULE_RECV_INTR,
>>>>> +};
>>>>> +struct notif_irq_info irq_info = { };
>>>>> +struct arm_smccc_1_2_regs resp;
>>>>> +unsigned int cpu;
>>>>> +
>>>>> +arm_smccc_1_2_smc(, );
>>>>> +if ( resp.a0 != FFA_SUCCESS_32 )
>>>>> +return;
>>>>> +
>>>>> +irq_info.irq = resp.a2;
>>>>> +if ( irq_info.irq < GIC_SGI_STATIC_MAX || irq_info.irq >= NR_GIC_SGI 
>>>>> )
>>>>> +{
>>>>> +printk(XENLOG_ERR "ffa: notification initialization failed: 
>>>>> conflicting SGI %u\n",
>>>>> +   irq_info.irq);
>>>>> +return;
>>>>> +}
>>>>> +
>>>>> +/*
>>>>> + * SGIs are per-CPU so we must enable the IRQ on each CPU. We use an
>>>>> + * IPI to call notif_irq_enable() on each CPU including the current
>>>>> + * CPU. The struct irqaction is preallocated since we can't allocate
>>>>> + * memory while in interrupt context.
>>>>> + */
>>>>> +for_each_online_cpu(cpu)
>>>>> +{
>>>>> +irq_info.action = xmalloc(struct irqaction);
>>>> 
>>>> You allocate one action per cpu but you have only one action pointer in 
>>>> your structure
>>>> which means you will overload the previously allocated one and lose track.
>>>> 
>>>> You should have a table of actions in your structure instead unless one 
>>>> action is
>>>> enough and can be reused on all cpus and in this case you should move out 
>>>> of
>>>> your loop the allocation part.
>>> 
>>> That shouldn't be needed because this is done in sequence only one CPU
>>> at a time.
>> 
>> Sorry i do not understand here.
>> You have a loop over each online cpu and on each loop you are assigning
>> irq_info.action with a newly allocated struct irqaction so you are in 
>> practice
>> overloading on cpu 2 the action that was allocated for cpu 1.
>> 
>> What do you mean by sequence here ?
>> 
> 
> My understanding is that for_each_online_cpu(cpu) loops over each cpu,
> one at a time. The call
> on_selected_cpus(cpumask_of(cpu), notif_irq_enable, _info, 1);
> returns after notif_irq_enable() has returned on the CPU in question
> thanks to the "1" (wait) parameter. So once it has returned _info
> isn't used by the other CPU any longer and we can assign a new value
> to irq_info.action.

Right so you loose track of what was assigned so you are not able to
free it.
If that is wanted then why saving this in irq.action as you will only have
there the one allocated for the last online cpu.

Cheers
Bertrand

> 
> Thanks,
> Jens

Re: [XEN PATCH v3 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 26 Apr 2024, at 14:11, Jens Wiklander  wrote:
> 
> Hi Bertrand,
> 
> On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
>  wrote:
>> 
>> Hi Jens,
>> 
>>> On 26 Apr 2024, at 10:47, Jens Wiklander  wrote:
>>> 
>>> Add support for FF-A notifications, currently limited to an SP (Secure
>>> Partition) sending an asynchronous notification to a guest.
>>> 
>>> Guests and Xen itself are made aware of pending notifications with an
>>> interrupt. The interrupt handler retrieves the notifications using the
>>> FF-A ABI and deliver them to their destinations.
>>> 
>>> Update ffa_partinfo_domain_init() to return error code like
>>> ffa_notif_domain_init().
>>> 
>>> Signed-off-by: Jens Wiklander 
>>> ---
>>> v2->v3:
>>> - Add a GUEST_ prefix and move FFA_NOTIF_PEND_INTR_ID and
>>> FFA_SCHEDULE_RECV_INTR_ID to public/arch-arm.h
>>> - Register the Xen SRI handler on each CPU using on_selected_cpus() and
>>> setup_irq()
>>> - Check that the SGI ID retrieved with FFA_FEATURE_SCHEDULE_RECV_INTR
>>> doesn't conflict with static SGI handlers
>>> 
>>> v1->v2:
>>> - Addressing review comments
>>> - Change ffa_handle_notification_{bind,unbind,set}() to take struct
>>> cpu_user_regs *regs as argument.
>>> - Update ffa_partinfo_domain_init() and ffa_notif_domain_init() to return
>>> an error code.
>>> - Fixing a bug in handle_features() for FFA_FEATURE_SCHEDULE_RECV_INTR.
>>> ---
>>> xen/arch/arm/irq.c  |   2 +-
>>> xen/arch/arm/tee/Makefile   |   1 +
>>> xen/arch/arm/tee/ffa.c  |  55 -
>>> xen/arch/arm/tee/ffa_notif.c| 378 
>>> xen/arch/arm/tee/ffa_partinfo.c |   9 +-
>>> xen/arch/arm/tee/ffa_private.h  |  56 -
>>> xen/include/public/arch-arm.h   |  14 ++
>>> 7 files changed, 507 insertions(+), 8 deletions(-)
>>> create mode 100644 xen/arch/arm/tee/ffa_notif.c
>>> 
>>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>>> index d7306aa64d50..5224898265a5 100644
>>> --- a/xen/arch/arm/irq.c
>>> +++ b/xen/arch/arm/irq.c
>>> @@ -155,7 +155,7 @@ void __init init_IRQ(void)
>>>{
>>>/* SGIs are always edge-triggered */
>>>if ( irq < NR_GIC_SGI )
>>> -local_irqs_type[irq] = DT_IRQ_TYPE_EDGE_RISING;
>>> +local_irqs_type[irq] = IRQ_TYPE_EDGE_RISING;
>>>else
>>>local_irqs_type[irq] = IRQ_TYPE_INVALID;
>>>}
>>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
>>> index f0112a2f922d..7c0f46f7f446 100644
>>> --- a/xen/arch/arm/tee/Makefile
>>> +++ b/xen/arch/arm/tee/Makefile
>>> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
>>> obj-$(CONFIG_FFA) += ffa_shm.o
>>> obj-$(CONFIG_FFA) += ffa_partinfo.o
>>> obj-$(CONFIG_FFA) += ffa_rxtx.o
>>> +obj-$(CONFIG_FFA) += ffa_notif.o
>>> obj-y += tee.o
>>> obj-$(CONFIG_OPTEE) += optee.o
>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>>> index 5209612963e1..912e905a27bd 100644
>>> --- a/xen/arch/arm/tee/ffa.c
>>> +++ b/xen/arch/arm/tee/ffa.c
>>> @@ -39,6 +39,9 @@
>>> *   - at most 32 shared memory regions per guest
>>> * o FFA_MSG_SEND_DIRECT_REQ:
>>> *   - only supported from a VM to an SP
>>> + * o FFA_NOTIFICATION_*:
>>> + *   - only supports global notifications, that is, per vCPU notifications
>>> + * are not supported
>>> *
>>> * There are some large locked sections with ffa_tx_buffer_lock and
>>> * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
>>> @@ -194,6 +197,8 @@ out:
>>> 
>>> static void handle_features(struct cpu_user_regs *regs)
>>> {
>>> +struct domain *d = current->domain;
>>> +struct ffa_ctx *ctx = d->arch.tee;
>>>uint32_t a1 = get_user_reg(regs, 1);
>>>unsigned int n;
>>> 
>>> @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
>>>BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
>>>ffa_set_regs_success(regs, 0, 0);
>>>break;
>>> +case FFA_FEATURE_NOTIF_PEND_INTR:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0);
>>> +else
>>> +ffa

Re: [XEN PATCH v3 0/5] FF-A notifications

[Bertrand Marquis]

Hi Jens

> On 26 Apr 2024, at 10:47, Jens Wiklander  wrote:
> 
> Hi,
> 
> This patch set adds support for FF-A notifications. We only support
> global notifications, per vCPU notifications remain unsupported.
> 
> The first three patches are further cleanup and can be merged before the
> rest if desired.
> 
> A physical SGI is used to make Xen aware of pending FF-A notifications. The
> physical SGI is selected by the SPMC in the secure world. Since it must not
> already be used by Xen the SPMC is in practice forced to donate one of the
> secure SGIs, but that's normally not a problem. The SGI handling in Xen is
> updated to support registration of handlers for SGIs that aren't statically
> assigned, that is, SGI IDs above GIC_SGI_MAX.

>From my point of view:
- patches 1 to 3 are ready to be commited.
- patch 4 will need a R-b from an other maintainer.
- patch 5 has still some stuff to be checked or fixed but could be
handled as a single patch if the rest or the serie is merged.


Regards
Bertrand


> 
> Thanks,
> Jens
> 
> v2->v3:
> - "xen/arm: ffa: support notification" and
>  "xen/arm: allow dynamically assigned SGI handlers" updated as requestsed,
>  details in each patch.
> 
> v1->v2:
> - "xen/arm: ffa: support notification" and
>  "xen/arm: allow dynamically assigned SGI handlers" updated as requestsed,
>  details in each patch.
> - Added Bertrands R-B for "xen/arm: ffa: refactor ffa_handle_call()",
>  "xen/arm: ffa: use ACCESS_ONCE()", and
>  "xen/arm: ffa: simplify ffa_handle_mem_share()"
> 
> Jens Wiklander (5):
>  xen/arm: ffa: refactor ffa_handle_call()
>  xen/arm: ffa: use ACCESS_ONCE()
>  xen/arm: ffa: simplify ffa_handle_mem_share()
>  xen/arm: allow dynamically assigned SGI handlers
>  xen/arm: ffa: support notification
> 
> xen/arch/arm/gic.c  |  12 +-
> xen/arch/arm/include/asm/gic.h  |   2 +-
> xen/arch/arm/irq.c  |  18 +-
> xen/arch/arm/tee/Makefile   |   1 +
> xen/arch/arm/tee/ffa.c  |  83 +--
> xen/arch/arm/tee/ffa_notif.c| 378 
> xen/arch/arm/tee/ffa_partinfo.c |   9 +-
> xen/arch/arm/tee/ffa_private.h  |  56 -
> xen/arch/arm/tee/ffa_shm.c  |  33 ++-
> xen/include/public/arch-arm.h   |  14 ++
> 10 files changed, 551 insertions(+), 55 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_notif.c
> 
> -- 
> 2.34.1
> 

Re: [XEN PATCH v3 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 26 Apr 2024, at 10:47, Jens Wiklander  wrote:
> 
> Add support for FF-A notifications, currently limited to an SP (Secure
> Partition) sending an asynchronous notification to a guest.
> 
> Guests and Xen itself are made aware of pending notifications with an
> interrupt. The interrupt handler retrieves the notifications using the
> FF-A ABI and deliver them to their destinations.
> 
> Update ffa_partinfo_domain_init() to return error code like
> ffa_notif_domain_init().
> 
> Signed-off-by: Jens Wiklander 
> ---
> v2->v3:
> - Add a GUEST_ prefix and move FFA_NOTIF_PEND_INTR_ID and
>  FFA_SCHEDULE_RECV_INTR_ID to public/arch-arm.h
> - Register the Xen SRI handler on each CPU using on_selected_cpus() and
>  setup_irq()
> - Check that the SGI ID retrieved with FFA_FEATURE_SCHEDULE_RECV_INTR
>  doesn't conflict with static SGI handlers
> 
> v1->v2:
> - Addressing review comments
> - Change ffa_handle_notification_{bind,unbind,set}() to take struct
>  cpu_user_regs *regs as argument.
> - Update ffa_partinfo_domain_init() and ffa_notif_domain_init() to return
>  an error code.
> - Fixing a bug in handle_features() for FFA_FEATURE_SCHEDULE_RECV_INTR.
> ---
> xen/arch/arm/irq.c  |   2 +-
> xen/arch/arm/tee/Makefile   |   1 +
> xen/arch/arm/tee/ffa.c  |  55 -
> xen/arch/arm/tee/ffa_notif.c| 378 
> xen/arch/arm/tee/ffa_partinfo.c |   9 +-
> xen/arch/arm/tee/ffa_private.h  |  56 -
> xen/include/public/arch-arm.h   |  14 ++
> 7 files changed, 507 insertions(+), 8 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_notif.c
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index d7306aa64d50..5224898265a5 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -155,7 +155,7 @@ void __init init_IRQ(void)
> {
> /* SGIs are always edge-triggered */
> if ( irq < NR_GIC_SGI )
> -local_irqs_type[irq] = DT_IRQ_TYPE_EDGE_RISING;
> +local_irqs_type[irq] = IRQ_TYPE_EDGE_RISING;
> else
> local_irqs_type[irq] = IRQ_TYPE_INVALID;
> }
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index f0112a2f922d..7c0f46f7f446 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
> obj-$(CONFIG_FFA) += ffa_shm.o
> obj-$(CONFIG_FFA) += ffa_partinfo.o
> obj-$(CONFIG_FFA) += ffa_rxtx.o
> +obj-$(CONFIG_FFA) += ffa_notif.o
> obj-y += tee.o
> obj-$(CONFIG_OPTEE) += optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 5209612963e1..912e905a27bd 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -39,6 +39,9 @@
>  *   - at most 32 shared memory regions per guest
>  * o FFA_MSG_SEND_DIRECT_REQ:
>  *   - only supported from a VM to an SP
> + * o FFA_NOTIFICATION_*:
> + *   - only supports global notifications, that is, per vCPU notifications
> + * are not supported
>  *
>  * There are some large locked sections with ffa_tx_buffer_lock and
>  * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
> @@ -194,6 +197,8 @@ out:
> 
> static void handle_features(struct cpu_user_regs *regs)
> {
> +struct domain *d = current->domain;
> +struct ffa_ctx *ctx = d->arch.tee;
> uint32_t a1 = get_user_reg(regs, 1);
> unsigned int n;
> 
> @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
> BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
> ffa_set_regs_success(regs, 0, 0);
> break;
> +case FFA_FEATURE_NOTIF_PEND_INTR:
> +if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, GUEST_FFA_NOTIF_PEND_INTR_ID, 0);
> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
> +if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0);
> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> +
> +case FFA_NOTIFICATION_BIND:
> +case FFA_NOTIFICATION_UNBIND:
> +case FFA_NOTIFICATION_GET:
> +case FFA_NOTIFICATION_SET:
> +case FFA_NOTIFICATION_INFO_GET_32:
> +case FFA_NOTIFICATION_INFO_GET_64:
> +if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, 0, 0);
> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> default:
> ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> break;
> @@ -305,6 +334,22 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
>  get_user_reg(regs, 1)),
>get_user_reg(regs, 3));
> break;
> +case FFA_NOTIFICATION_BIND:
> +e = ffa_handle_notification_bind(regs);
> +break;
> +case FFA_NOTIFICATION_UNBIND:
> +e = 

Re: [XEN PATCH v2 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 23 Apr 2024, at 17:26, Jens Wiklander  wrote:
> 
> Hi Julien,
> 
> On Mon, Apr 22, 2024 at 1:40 PM Julien Grall  wrote:
>> 
>> Hi Jens,
>> 
>> This is not a full review of the code. I will let Bertrand doing it.
>> 
>> On 22/04/2024 08:37, Jens Wiklander wrote:
>>> +void ffa_notif_init(void)
>>> +{
>>> +const struct arm_smccc_1_2_regs arg = {
>>> +.a0 = FFA_FEATURES,
>>> +.a1 = FFA_FEATURE_SCHEDULE_RECV_INTR,
>>> +};
>>> +struct arm_smccc_1_2_regs resp;
>>> +unsigned int irq;
>>> +int ret;
>>> +
>>> +arm_smccc_1_2_smc(, );
>>> +if ( resp.a0 != FFA_SUCCESS_32 )
>>> +return;
>>> +
>>> +irq = resp.a2;
>>> +if ( irq >= NR_GIC_SGI )
>>> +irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
>>> +ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
>> 
>> If I am not mistaken, ffa_notif_init() is only called once on the boot
>> CPU. However, request_irq() needs to be called on every CPU so the
>> callback is registered every where and the interrupt enabled.
>> 
>> I know the name of the function is rather confusing. So can you confirm
>> this is what you expected?
> 
> Good catch, no this wasn't what I expected. I'll need to change this.
> 
>> 
>> [...]
>> 
>>> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
>>> index 98236cbf14a3..ef8ffd4526bd 100644
>>> --- a/xen/arch/arm/tee/ffa_private.h
>>> +++ b/xen/arch/arm/tee/ffa_private.h
>>> @@ -25,6 +25,7 @@
>>>  #define FFA_RET_DENIED  -6
>>>  #define FFA_RET_RETRY   -7
>>>  #define FFA_RET_ABORTED -8
>>> +#define FFA_RET_NO_DATA -9
>>> 
>>>  /* FFA_VERSION helpers */
>>>  #define FFA_VERSION_MAJOR_SHIFT 16U
>>> @@ -97,6 +98,18 @@
>>>   */
>>>  #define FFA_MAX_SHM_COUNT   32
>>> 
>>> +/*
>>> + * TODO How to manage the available SGIs? SGI 8-15 seem to be entirely
>>> + * unused, but that may change.
>> 
>> Are the value below intended for the guests? If so, can they be moved in
>> public/arch-arm.h along with the others guest interrupts?
> 
> Yes, I'll move it.
> 
>> 
>>> + *
>>> + * SGI is the preferred delivery mechanism. SGIs 8-15 are normally not used
>>> + * by a guest as they in a non-virtualized system typically are assigned to
>>> + * the secure world. Here we're free to use SGI 8-15 since they are virtual
>>> + * and have nothing to do with the secure world.
>> 
>> Do you have a pointer to the specification?
> 
> There's one at the top of arch/arm/tee/ffa.c,
> https://developer.arm.com/documentation/den0077/e
> Do you want the link close to the defines when I've moved them to
> public/arch-arm.h?
> Or is it perhaps better to give a link to "Arm Base System
> Architecture v1.0C", https://developer.arm.com/documentation/den0094/
> instead?

I would say we need the link to Arm Base System Architecture in arch-arm.

Regards
Bertrand

> 
> Thanks,
> Jens

Re: [XEN PATCH v2 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Julien,

> On 23 Apr 2024, at 17:16, Julien Grall  wrote:
> 
> Hi Bertrand,
> 
> On 23/04/2024 16:12, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Apr 2024, at 13:40, Julien Grall  wrote:
>>> 
>>> Hi Jens,
>>> 
>>> This is not a full review of the code. I will let Bertrand doing it.
>>> 
>>> On 22/04/2024 08:37, Jens Wiklander wrote:
>>>> +void ffa_notif_init(void)
>>>> +{
>>>> +const struct arm_smccc_1_2_regs arg = {
>>>> +.a0 = FFA_FEATURES,
>>>> +.a1 = FFA_FEATURE_SCHEDULE_RECV_INTR,
>>>> +};
>>>> +struct arm_smccc_1_2_regs resp;
>>>> +unsigned int irq;
>>>> +int ret;
>>>> +
>>>> +arm_smccc_1_2_smc(, );
>>>> +if ( resp.a0 != FFA_SUCCESS_32 )
>>>> +return;
>>>> +
>>>> +irq = resp.a2;
>>>> +if ( irq >= NR_GIC_SGI )
>>>> +irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
>>>> +ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
>>> 
>>> If I am not mistaken, ffa_notif_init() is only called once on the boot CPU. 
>>> However, request_irq() needs to be called on every CPU so the callback is 
>>> registered every where and the interrupt enabled.
>>> 
>>> I know the name of the function is rather confusing. So can you confirm 
>>> this is what you expected?
>>> 
>>> [...]
>>> 
>>>> diff --git a/xen/arch/arm/tee/ffa_private.h 
>>>> b/xen/arch/arm/tee/ffa_private.h
>>>> index 98236cbf14a3..ef8ffd4526bd 100644
>>>> --- a/xen/arch/arm/tee/ffa_private.h
>>>> +++ b/xen/arch/arm/tee/ffa_private.h
>>>> @@ -25,6 +25,7 @@
>>>>  #define FFA_RET_DENIED  -6
>>>>  #define FFA_RET_RETRY   -7
>>>>  #define FFA_RET_ABORTED -8
>>>> +#define FFA_RET_NO_DATA -9
>>>>/* FFA_VERSION helpers */
>>>>  #define FFA_VERSION_MAJOR_SHIFT 16U
>>>> @@ -97,6 +98,18 @@
>>>>   */
>>>>  #define FFA_MAX_SHM_COUNT   32
>>>>  +/*
>>>> + * TODO How to manage the available SGIs? SGI 8-15 seem to be entirely
>>>> + * unused, but that may change.
>>> 
>>> Are the value below intended for the guests? If so, can they be moved in 
>>> public/arch-arm.h along with the others guest interrupts?
>> The values are to be used by the guest but they will discover them through 
>> the FFA_FEATURES ABI so I do not think those
>> should belong the public headers.
> 
> Sorry I should have been clearer. The values in the public headers are not 
> meant for the guest. They are meant for a common understanding between the 
> toolstack and Xen of the guest layout (memory + interrupts).
> 
> I know that some of the guests started to rely on it. But this is against our 
> policy:
> 
> * These are defined for consistency between the tools and the
> * hypervisor. Guests must not rely on these hardcoded values but
> * should instead use the FDT.
> 
> In this case, even if this is only used by Xen (today), I would argue they 
> should defined at the same place because it is easier to understand the 
> layout if it is in one place.

I see, that makes sense then to add them there.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [XEN PATCH v2 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Julien,

> On 22 Apr 2024, at 13:40, Julien Grall  wrote:
> 
> Hi Jens,
> 
> This is not a full review of the code. I will let Bertrand doing it.
> 
> On 22/04/2024 08:37, Jens Wiklander wrote:
>> +void ffa_notif_init(void)
>> +{
>> +const struct arm_smccc_1_2_regs arg = {
>> +.a0 = FFA_FEATURES,
>> +.a1 = FFA_FEATURE_SCHEDULE_RECV_INTR,
>> +};
>> +struct arm_smccc_1_2_regs resp;
>> +unsigned int irq;
>> +int ret;
>> +
>> +arm_smccc_1_2_smc(, );
>> +if ( resp.a0 != FFA_SUCCESS_32 )
>> +return;
>> +
>> +irq = resp.a2;
>> +if ( irq >= NR_GIC_SGI )
>> +irq_set_type(irq, IRQ_TYPE_EDGE_RISING);
>> +ret = request_irq(irq, 0, notif_irq_handler, "FF-A notif", NULL);
> 
> If I am not mistaken, ffa_notif_init() is only called once on the boot CPU. 
> However, request_irq() needs to be called on every CPU so the callback is 
> registered every where and the interrupt enabled.
> 
> I know the name of the function is rather confusing. So can you confirm this 
> is what you expected?
> 
> [...]
> 
>> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h
>> index 98236cbf14a3..ef8ffd4526bd 100644
>> --- a/xen/arch/arm/tee/ffa_private.h
>> +++ b/xen/arch/arm/tee/ffa_private.h
>> @@ -25,6 +25,7 @@
>>  #define FFA_RET_DENIED  -6
>>  #define FFA_RET_RETRY   -7
>>  #define FFA_RET_ABORTED -8
>> +#define FFA_RET_NO_DATA -9
>>/* FFA_VERSION helpers */
>>  #define FFA_VERSION_MAJOR_SHIFT 16U
>> @@ -97,6 +98,18 @@
>>   */
>>  #define FFA_MAX_SHM_COUNT   32
>>  +/*
>> + * TODO How to manage the available SGIs? SGI 8-15 seem to be entirely
>> + * unused, but that may change.
> 
> Are the value below intended for the guests? If so, can they be moved in 
> public/arch-arm.h along with the others guest interrupts?

The values are to be used by the guest but they will discover them through the 
FFA_FEATURES ABI so I do not think those
should belong the public headers.

Cheers
Bertrand

> 
>> + *
>> + * SGI is the preferred delivery mechanism. SGIs 8-15 are normally not used
>> + * by a guest as they in a non-virtualized system typically are assigned to
>> + * the secure world. Here we're free to use SGI 8-15 since they are virtual
>> + * and have nothing to do with the secure world.
> 
> Do you have a pointer to the specification?
> 
> [...]
> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [XEN PATCH v2 4/5] xen/arm: allow dynamically assigned SGI handlers

[Bertrand Marquis]

Hi Julien,

> On 23 Apr 2024, at 14:37, Bertrand Marquis  wrote:
> 
> Hi Julien,
> 
>> On 23 Apr 2024, at 13:05, Julien Grall  wrote:
>> 
>> 
>> 
>> On 23/04/2024 10:35, Jens Wiklander wrote:
>>> Hi Julien,
>> 
>> Hi Jens,
>> 
>>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall  wrote:
>>>> 
>>>> Hi Jens,
>>>> 
>>>> On 22/04/2024 08:37, Jens Wiklander wrote:
>>>>> Updates so request_irq() can be used with a dynamically assigned SGI irq
>>>>> as input. This prepares for a later patch where an FF-A schedule
>>>>> receiver interrupt handler is installed for an SGI generated by the
>>>>> secure world.
>>>> 
>>>> I would like to understand the use-case a bit more. Who is responsible
>>>> to decide the SGI number? Is it Xen or the firmware?
>>>> 
>>>> If the later, how can we ever guarantee the ID is not going to clash
>>>> with what the OS/hypervisor is using? Is it described in a
>>>> specification? If so, please give a pointer.
>>> The firmware decides the SGI number. Given that the firmware doesn't
>>> know which SGIs Xen is using it typically needs to donate one of the
>>> secure SGIs, but that is transparent to Xen.
>> 
>> Right this is my concern. The firmware decides the number, but at the same 
>> time Xen thinks that all the SGIs are available (AFAIK there is only one 
>> set).
>> 
>> What I would like to see is some wording from a spec indicating that the 
>> SGIs ID reserved by the firmware will not be clashing with the one used by 
>> Xen.
> 
> The idea is that the only SGI reserved for secure are used by the secure 
> world (in fact it is the SPMC in the secure world who tells us which SGI it 
> will generate).
> So in theory that means it will always use an SGI between 8 and 15.
> 
> Now it could make sense in fact to check that the number returned by the 
> firmware (or SPMC) is not clashing with Xen as it is a recommendation in the 
> spec and
> in fact an implementation might do something different.
> 
> Right now there is no spec that will say that it will never clash with the 
> one used by Xen as the FF-A spec is not enforcing anything here so it would 
> be a good idea
> to check and disable FF-A with a proper error message if this happens.


After some more digging here is what is recommended by Arm in the Arm Base 
System Architecture v1.0C [1]:

"The system shall implement at least eight Non-secure SGIs, assigned to 
interrupt IDs 0-7."

So basically as long as Xen is using SGIs 0-7 it is safe as those shall never 
be used by the secure world.
Now i do agree that we should check that whatever is returned by the firmware 
is not conflicting with what
is used by Xen.

Cheers
Bertrand

[1] https://developer.arm.com/documentation/den0094/

Re: [XEN PATCH v2 4/5] xen/arm: allow dynamically assigned SGI handlers

[Bertrand Marquis]

Hi Julien,

> On 23 Apr 2024, at 13:05, Julien Grall  wrote:
> 
> 
> 
> On 23/04/2024 10:35, Jens Wiklander wrote:
>> Hi Julien,
> 
> Hi Jens,
> 
>> On Mon, Apr 22, 2024 at 12:57 PM Julien Grall  wrote:
>>> 
>>> Hi Jens,
>>> 
>>> On 22/04/2024 08:37, Jens Wiklander wrote:
 Updates so request_irq() can be used with a dynamically assigned SGI irq
 as input. This prepares for a later patch where an FF-A schedule
 receiver interrupt handler is installed for an SGI generated by the
 secure world.
>>> 
>>> I would like to understand the use-case a bit more. Who is responsible
>>> to decide the SGI number? Is it Xen or the firmware?
>>> 
>>> If the later, how can we ever guarantee the ID is not going to clash
>>> with what the OS/hypervisor is using? Is it described in a
>>> specification? If so, please give a pointer.
>> The firmware decides the SGI number. Given that the firmware doesn't
>> know which SGIs Xen is using it typically needs to donate one of the
>> secure SGIs, but that is transparent to Xen.
> 
> Right this is my concern. The firmware decides the number, but at the same 
> time Xen thinks that all the SGIs are available (AFAIK there is only one set).
> 
> What I would like to see is some wording from a spec indicating that the SGIs 
> ID reserved by the firmware will not be clashing with the one used by Xen.

The idea is that the only SGI reserved for secure are used by the secure world 
(in fact it is the SPMC in the secure world who tells us which SGI it will 
generate).
So in theory that means it will always use an SGI between 8 and 15.

Now it could make sense in fact to check that the number returned by the 
firmware (or SPMC) is not clashing with Xen as it is a recommendation in the 
spec and
in fact an implementation might do something different.

Right now there is no spec that will say that it will never clash with the one 
used by Xen as the FF-A spec is not enforcing anything here so it would be a 
good idea
to check and disable FF-A with a proper error message if this happens.

Cheers
Bertrand

> 
>>> 
 
 gic_route_irq_to_xen() don't gic_set_irq_type() for SGIs since they are
 always edge triggered.
 
 gic_interrupt() is updated to route the dynamically assigned SGIs to
 do_IRQ() instead of do_sgi(). The latter still handles the statically
 assigned SGI handlers like for instance GIC_SGI_CALL_FUNCTION.
 
 Signed-off-by: Jens Wiklander 
 ---
 v1->v2
 - Update patch description as requested
 ---
   xen/arch/arm/gic.c | 5 +++--
   xen/arch/arm/irq.c | 7 +--
>>> 
>>> I am not sure where to write the comment. But I think the comment on top
>>> of irq_set_affinity() in setup_irq() should also be updated.
>>> 
   2 files changed, 8 insertions(+), 4 deletions(-)
 
 diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
 index 44c40e86defe..e9aeb7138455 100644
 --- a/xen/arch/arm/gic.c
 +++ b/xen/arch/arm/gic.c
 @@ -117,7 +117,8 @@ void gic_route_irq_to_xen(struct irq_desc *desc, 
 unsigned int priority)
 
   desc->handler = gic_hw_ops->gic_host_irq_type;
 
 -gic_set_irq_type(desc, desc->arch.type);
 +if ( desc->irq >= NR_GIC_SGI)
 +gic_set_irq_type(desc, desc->arch.type);
>>> 
>>> So above, you say that the SGIs are always edge-triggered interrupt. So
>>> I assume desc->arch.type. So are you skipping the call because it is
>>> unnessary or it could do the wrong thing?
>>> 
>>> Ideally, the outcome of the answer be part of the comment on top of the
>>> check.
>> gic_set_irq_type() has an assert "ASSERT(type != IRQ_TYPE_INVALID)"
>> which is triggered without this check.
>> So it's both unnecessary and wrong. I suppose we could update the
>> bookkeeping of all SGIs to be edge-triggered instead of
>> IRQ_TYPE_INVALID. It would still be unnecessary though. What do you
>> suggest?
> 
> I would rather prefer if we update the book-keeping for all the SGIs.
> 
> [...]
> 
>>> 
   {
   isb();
   do_IRQ(regs, irq, is_fiq);
 diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
 index bcce80a4d624..fdb214560978 100644
 --- a/xen/arch/arm/irq.c
 +++ b/xen/arch/arm/irq.c
 @@ -224,9 +224,12 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int 
 irq, int is_fiq)
 
   perfc_incr(irqs);
 
 -ASSERT(irq >= 16); /* SGIs do not come down this path */
 +/* Statically assigned SGIs do not come down this path */
 +ASSERT(irq >= GIC_SGI_MAX);
>>> 
>>> 
>>> With this change, I think the path with vgic_inject_irq() now needs to
>>> gain an ASSERT(irq >= NR_GIC_SGI) because the path is not supposed to be
>>> taken for SGIs.
>> I'm sorry, I don't see the connection. If I add
>> ASSERT(virq >= NR_GIC_SGI);
>> at the top of vgic_inject_irq() it will panic when injecting a
>> Schedule Receiver or Notification Pending Interrupt for a guest.
> 
> If you look at 

Re: [PATCH v2] docs/misra: add Rule 16.4

[Bertrand Marquis]

Hi Stefano,

> On 14 Mar 2024, at 22:50, Stefano Stabellini  wrote:
> 
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes in v2:
> - mention -Werror
> - change the position of the in-code comment in the example
> - use "notifier pattern" in the example
> - clarify it is only an example
> ---
> docs/misra/rules.rst | 25 +
> 1 file changed, 25 insertions(+)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index 1e134ccebc..5c84091e45 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -478,6 +478,31 @@ maintainers if you want to suggest a change.
>  - In addition to break, also other unconditional flow control statements
>such as continue, return, goto are allowed.
> 
> +   * - `Rule 16.4 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_04.c>`_
> + - Required
> + - Every switch statement shall have a default label
> + - Switch statements with enums as controlling expression don't need
> +   a default label as gcc -Wall enables -Wswitch which warns (and
> +   breaks the build as we use -Werror) if one of the enum labels is
> +   missing from the switch.
> +
> +   Switch statements with integer types as controlling expression
> +   should have a default label:
> +
> +   - if the switch is expected to handle all possible cases
> + explicitly, then a default label shall be added to handle
> + unexpected error conditions, using BUG(), ASSERT(), WARN(),
> + domain_crash(), or other appropriate methods;
> +
> +   - if the switch is expected to handle a subset of all possible
> + cases, then an empty default label shall be added with an
> + in-code comment on top of the default label with a reason and
> + when possible a more detailed explanation. Example::
> +
> + default:
> + /* Notifier pattern */
> + break;
> +
>* - `Rule 16.2 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_02.c>`_
>  - Required
>  - A switch label shall only be used when the most closely-enclosing
> -- 
> 2.25.1
> 

Re: [PATCH v3] docs/misra/rules.rst: add rule 5.5

[Bertrand Marquis]

Hi Stefano,

> On 15 Mar 2024, at 01:35, Stefano Stabellini  wrote:
> 
> Signed-off-by: Stefano Stabellini 

With the semicolon comment from Jan addressed:

Acked-by: Bertrand Marquis 

Cheers
Bertrand

Re: [PATCH v2 1/4] docs: add xen_ulong_t to the documented integers sizes/alignments

[Bertrand Marquis]

Hi Julien,

> On 15 Apr 2024, at 12:08, Julien Grall  wrote:
> 
> Hi Bertrand,
> 
> On 15/04/2024 08:48, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 12 Apr 2024, at 19:01, Julien Grall  wrote:
>>> 
>>> 
>>> 
>>> On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis  
>>> wrote:
>>> Hi Julien,
>>> 
>>>> On 12 Apr 2024, at 15:53, Julien Grall  wrote:
>>>> 
>>>> 
>>>> 
>>>> On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini  
>>>> wrote:
>>>> On Wed, 10 Apr 2024, Julien Grall wrote:
>>>>> On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini 
>>>>>  wrote:
>>>>>   xen_ulong_t is widely used in public headers.
>>>>> 
>>>>>   Signed-off-by: Stefano Stabellini 
>>>>>   ---
>>>>> 
>>>>>   Given that xen_ulong_t is used in public headers there could be a 
>>>>> better
>>>>>   place for documenting it but this was the most straightforward to 
>>>>> add.
>>>>>   ---
>>>>>docs/misra/C-language-toolchain.rst | 11 +++
>>>>>1 file changed, 11 insertions(+)
>>>>> 
>>>>>   diff --git a/docs/misra/C-language-toolchain.rst 
>>>>> b/docs/misra/C-language-toolchain.rst
>>>>>   index 5ddfe7bdbe..7a334260e6 100644
>>>>>   --- a/docs/misra/C-language-toolchain.rst
>>>>>   +++ b/docs/misra/C-language-toolchain.rst
>>>>>   @@ -531,6 +531,17 @@ A summary table of data types, sizes and 
>>>>> alignment is below:
>>>>> - 64 bits
>>>>> - x86_64, ARMv8-A AArch64, RV64, PPC64
>>>>> 
>>>>>   +   * - xen_ulong_t
>>>>>   + - 32 bits
>>>>>   + - 32 bits
>>>>>   + - x86_32
>>>>>   +
>>>>>   +   * - xen_ulong_t
>>>>>   + - 64 bits
>>>>>   + - 64 bits
>>>>>   + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, 
>>>>> ARMv8-R
>>>>>   +   AArch32, ARMv7-A
>>>>> 
>>>>> 
>>>>> We support neither ARMv8-R nor ARMv8-A Aarch32.
>>>>> 
>>>>> I could possibly accept the latter because it works to. But the former is 
>>>>> so far misleading.
>>>> 
>>>> Yes I think you are right. Moreover this document
>>>> (C-language-toolchain.rst) is meant for the Xen build. While this patch
>>>> is trying to document the types used in the public headers for the
>>>> external-facing ABI.
>>>> 
>>>> I'll move the information this patch is adding to a separate document,
>>>> specific to the public headers. I will only add the architectures
>>>> currently working: I'll add ARMv8-A Aarch32 because although it is
>>>> unsupported it is interesting to know the size of xen_ulong_t for
>>>> aarch32 in the public headers. I will remove ARMv8-R as it is not
>>>> available upstream.
>>>> 
>>>> Thinking a bit more. What about Armv9? Rather than listing each version, 
>>>> should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later?
>>> 
>>> Definitely you are right here but as for Armv8-R, Armv9 is not something 
>>> that we explicitely support right now (even though it should work).
>>> 
>>> I am confused with the comparison. I thought you can’t boot Xen at all on 
>>> Armv8-R. But you can on Armv9-A as this just Armv8-A + features the 
>>> software don’t need to use.
>>> 
>>> Did you intend to draw the comparison with Armv8-A Aarch32?
>> Yes in my mind armv9 even if currently working it is not something 
>> officially supported so it is in the same state as armv8 aarch32.
> 
> AFAICT, Stefano said he will add ARMv8-A AArch32, so we should be consistent 
> and add Armv9-A in the list.

Yes that makes sense, I agree.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v2 1/4] docs: add xen_ulong_t to the documented integers sizes/alignments

[Bertrand Marquis]

Hi Julien,

> On 12 Apr 2024, at 19:01, Julien Grall  wrote:
> 
> 
> 
> On Fri, 12 Apr 2024 at 11:30, Bertrand Marquis  
> wrote:
> Hi Julien,
> 
> > On 12 Apr 2024, at 15:53, Julien Grall  wrote:
> > 
> > 
> > 
> > On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini  
> > wrote:
> > On Wed, 10 Apr 2024, Julien Grall wrote:
> > > On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini 
> > >  wrote:
> > >   xen_ulong_t is widely used in public headers.
> > > 
> > >   Signed-off-by: Stefano Stabellini 
> > >   ---
> > > 
> > >   Given that xen_ulong_t is used in public headers there could be a 
> > > better
> > >   place for documenting it but this was the most straightforward to 
> > > add.
> > >   ---
> > >docs/misra/C-language-toolchain.rst | 11 +++
> > >1 file changed, 11 insertions(+)
> > > 
> > >   diff --git a/docs/misra/C-language-toolchain.rst 
> > > b/docs/misra/C-language-toolchain.rst
> > >   index 5ddfe7bdbe..7a334260e6 100644
> > >   --- a/docs/misra/C-language-toolchain.rst
> > >   +++ b/docs/misra/C-language-toolchain.rst
> > >   @@ -531,6 +531,17 @@ A summary table of data types, sizes and 
> > > alignment is below:
> > > - 64 bits
> > > - x86_64, ARMv8-A AArch64, RV64, PPC64
> > > 
> > >   +   * - xen_ulong_t
> > >   + - 32 bits
> > >   + - 32 bits
> > >   + - x86_32
> > >   +
> > >   +   * - xen_ulong_t
> > >   + - 64 bits
> > >   + - 64 bits
> > >   + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, 
> > > ARMv8-R
> > >   +   AArch32, ARMv7-A
> > > 
> > > 
> > > We support neither ARMv8-R nor ARMv8-A Aarch32.
> > > 
> > > I could possibly accept the latter because it works to. But the former is 
> > > so far misleading.
> > 
> > Yes I think you are right. Moreover this document
> > (C-language-toolchain.rst) is meant for the Xen build. While this patch
> > is trying to document the types used in the public headers for the
> > external-facing ABI.
> > 
> > I'll move the information this patch is adding to a separate document,
> > specific to the public headers. I will only add the architectures
> > currently working: I'll add ARMv8-A Aarch32 because although it is
> > unsupported it is interesting to know the size of xen_ulong_t for
> > aarch32 in the public headers. I will remove ARMv8-R as it is not
> > available upstream.
> > 
> > Thinking a bit more. What about Armv9? Rather than listing each version, 
> > should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later?
> 
> Definitely you are right here but as for Armv8-R, Armv9 is not something that 
> we explicitely support right now (even though it should work).
> 
> I am confused with the comparison. I thought you can’t boot Xen at all on 
> Armv8-R. But you can on Armv9-A as this just Armv8-A + features the software 
> don’t need to use.
> 
> Did you intend to draw the comparison with Armv8-A Aarch32?

Yes in my mind armv9 even if currently working it is not something officially 
supported so it is in the same state as armv8 aarch32.

Armv8-R currently cannot work at all so it is a different state.

Cheers
Bertrand

> 
> Cheers,
> 
> 
> 
> Cheers
> Bertrand

Re: [PATCH v2 1/4] docs: add xen_ulong_t to the documented integers sizes/alignments

[Bertrand Marquis]

Hi Julien,

> On 12 Apr 2024, at 15:53, Julien Grall  wrote:
> 
> 
> 
> On Thu, 11 Apr 2024 at 18:08, Stefano Stabellini  
> wrote:
> On Wed, 10 Apr 2024, Julien Grall wrote:
> > On Wed, 10 Apr 2024 at 19:47, Stefano Stabellini 
> >  wrote:
> >   xen_ulong_t is widely used in public headers.
> > 
> >   Signed-off-by: Stefano Stabellini 
> >   ---
> > 
> >   Given that xen_ulong_t is used in public headers there could be a 
> > better
> >   place for documenting it but this was the most straightforward to add.
> >   ---
> >docs/misra/C-language-toolchain.rst | 11 +++
> >1 file changed, 11 insertions(+)
> > 
> >   diff --git a/docs/misra/C-language-toolchain.rst 
> > b/docs/misra/C-language-toolchain.rst
> >   index 5ddfe7bdbe..7a334260e6 100644
> >   --- a/docs/misra/C-language-toolchain.rst
> >   +++ b/docs/misra/C-language-toolchain.rst
> >   @@ -531,6 +531,17 @@ A summary table of data types, sizes and 
> > alignment is below:
> > - 64 bits
> > - x86_64, ARMv8-A AArch64, RV64, PPC64
> > 
> >   +   * - xen_ulong_t
> >   + - 32 bits
> >   + - 32 bits
> >   + - x86_32
> >   +
> >   +   * - xen_ulong_t
> >   + - 64 bits
> >   + - 64 bits
> >   + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, ARMv8-R
> >   +   AArch32, ARMv7-A
> > 
> > 
> > We support neither ARMv8-R nor ARMv8-A Aarch32.
> > 
> > I could possibly accept the latter because it works to. But the former is 
> > so far misleading.
> 
> Yes I think you are right. Moreover this document
> (C-language-toolchain.rst) is meant for the Xen build. While this patch
> is trying to document the types used in the public headers for the
> external-facing ABI.
> 
> I'll move the information this patch is adding to a separate document,
> specific to the public headers. I will only add the architectures
> currently working: I'll add ARMv8-A Aarch32 because although it is
> unsupported it is interesting to know the size of xen_ulong_t for
> aarch32 in the public headers. I will remove ARMv8-R as it is not
> available upstream.
> 
> Thinking a bit more. What about Armv9? Rather than listing each version, 
> should we instead use ARMv7-A aarch32 and later, ARMv8-A aarch64 and later?

Definitely you are right here but as for Armv8-R, Armv9 is not something that 
we explicitely support right now (even though it should work).

Cheers
Bertrand

Re: [XEN PATCH v1 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 10 Apr 2024, at 17:45, Jens Wiklander  wrote:
> 
> On Tue, Apr 9, 2024 at 5:36 PM Jens Wiklander  
> wrote:
>> 
>> Add support for FF-A notifications, currently limited to an SP (Secure
>> Partition) sending an asynchronous notification to a guest.
>> 
>> Guests and Xen itself are made aware of pending notifications with an
>> interrupt. The interrupt handler retrieves the notifications using the
>> FF-A ABI and deliver them to their destinations.
>> 
>> Signed-off-by: Jens Wiklander 
>> ---
>> xen/arch/arm/tee/Makefile  |   1 +
>> xen/arch/arm/tee/ffa.c |  58 ++
>> xen/arch/arm/tee/ffa_notif.c   | 319 +
>> xen/arch/arm/tee/ffa_private.h |  71 
>> 4 files changed, 449 insertions(+)
>> create mode 100644 xen/arch/arm/tee/ffa_notif.c
>> 
>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
>> index f0112a2f922d..7c0f46f7f446 100644
>> --- a/xen/arch/arm/tee/Makefile
>> +++ b/xen/arch/arm/tee/Makefile
>> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
>> obj-$(CONFIG_FFA) += ffa_shm.o
>> obj-$(CONFIG_FFA) += ffa_partinfo.o
>> obj-$(CONFIG_FFA) += ffa_rxtx.o
>> +obj-$(CONFIG_FFA) += ffa_notif.o
>> obj-y += tee.o
>> obj-$(CONFIG_OPTEE) += optee.o
>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>> index 5209612963e1..ce9757bfeed1 100644
>> --- a/xen/arch/arm/tee/ffa.c
>> +++ b/xen/arch/arm/tee/ffa.c
>> @@ -39,6 +39,9 @@
>>  *   - at most 32 shared memory regions per guest
>>  * o FFA_MSG_SEND_DIRECT_REQ:
>>  *   - only supported from a VM to an SP
>> + * o FFA_NOTIFICATION_*:
>> + *   - only supports global notifications, that is, per vCPU notifications
>> + * are not supported
>>  *
>>  * There are some large locked sections with ffa_tx_buffer_lock and
>>  * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
>> @@ -194,6 +197,8 @@ out:
>> 
>> static void handle_features(struct cpu_user_regs *regs)
>> {
>> +struct domain *d = current->domain;
>> +struct ffa_ctx *ctx = d->arch.tee;
>> uint32_t a1 = get_user_reg(regs, 1);
>> unsigned int n;
>> 
>> @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
>> BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
>> ffa_set_regs_success(regs, 0, 0);
>> break;
>> +case FFA_FEATURE_NOTIF_PEND_INTR:
>> +if ( ctx->notif.enabled )
>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>> +else
>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>> +break;
>> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
>> +if ( ctx->notif.enabled )
>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>> +else
>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>> +break;
> 
> With the recently posted kernel patch
> https://lore.kernel.org/all/20240410-ffa_npi_support-v1-3-1a5223391...@arm.com/
> we need to decide which feature interrupt to return since the kernel
> will only install a handle for the first it finds. Right now I propose
> to to not report FFA_FEATURE_SCHEDULE_RECV_INTR. When the time comes
> to use a secondary scheduler we'll need to report the SRI instead.


We just had a meeting with Sudeep to discuss that matter and he agreed that
he would register the interrupt handler for all the interrupts available so that
we can keep a model where we will generate SRIs only to a secondary scheduler
and NPI for notification interrupts (so that the VM does not do a INFO_GET when
not required).

We will have to report both as any VM could act as secondary scheduler for SPs
in theory (we might need at some point a parameter for that) but for now those
should only be generated to Dom0 if there are pending notifications for SPs.

Cheers
Bertrand

Re: [XEN PATCH v1 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 10 Apr 2024, at 16:27, Jens Wiklander  wrote:
> 
> On Wed, Apr 10, 2024 at 9:49 AM Bertrand Marquis
>  wrote:
>> 
>> Hi Jens,
>> 
>>> On 9 Apr 2024, at 17:36, Jens Wiklander  wrote:
>>> 
>>> Add support for FF-A notifications, currently limited to an SP (Secure
>>> Partition) sending an asynchronous notification to a guest.
>>> 
>>> Guests and Xen itself are made aware of pending notifications with an
>>> interrupt. The interrupt handler retrieves the notifications using the
>>> FF-A ABI and deliver them to their destinations.
>>> 
>>> Signed-off-by: Jens Wiklander 
>>> ---
>>> xen/arch/arm/tee/Makefile  |   1 +
>>> xen/arch/arm/tee/ffa.c |  58 ++
>>> xen/arch/arm/tee/ffa_notif.c   | 319 +
>>> xen/arch/arm/tee/ffa_private.h |  71 
>>> 4 files changed, 449 insertions(+)
>>> create mode 100644 xen/arch/arm/tee/ffa_notif.c
>>> 
>>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
>>> index f0112a2f922d..7c0f46f7f446 100644
>>> --- a/xen/arch/arm/tee/Makefile
>>> +++ b/xen/arch/arm/tee/Makefile
>>> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
>>> obj-$(CONFIG_FFA) += ffa_shm.o
>>> obj-$(CONFIG_FFA) += ffa_partinfo.o
>>> obj-$(CONFIG_FFA) += ffa_rxtx.o
>>> +obj-$(CONFIG_FFA) += ffa_notif.o
>>> obj-y += tee.o
>>> obj-$(CONFIG_OPTEE) += optee.o
>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>>> index 5209612963e1..ce9757bfeed1 100644
>>> --- a/xen/arch/arm/tee/ffa.c
>>> +++ b/xen/arch/arm/tee/ffa.c
>>> @@ -39,6 +39,9 @@
>>> *   - at most 32 shared memory regions per guest
>>> * o FFA_MSG_SEND_DIRECT_REQ:
>>> *   - only supported from a VM to an SP
>>> + * o FFA_NOTIFICATION_*:
>>> + *   - only supports global notifications, that is, per vCPU notifications
>>> + * are not supported
>>> *
>>> * There are some large locked sections with ffa_tx_buffer_lock and
>>> * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
>>> @@ -194,6 +197,8 @@ out:
>>> 
>>> static void handle_features(struct cpu_user_regs *regs)
>>> {
>>> +struct domain *d = current->domain;
>>> +struct ffa_ctx *ctx = d->arch.tee;
>>>uint32_t a1 = get_user_reg(regs, 1);
>>>unsigned int n;
>>> 
>>> @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
>>>BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
>>>ffa_set_regs_success(regs, 0, 0);
>>>break;
>>> +case FFA_FEATURE_NOTIF_PEND_INTR:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>>> +else
>>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>> +break;
>>> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>> 
>> This should return the RECV_INTR, not the PEND one.
> 
> Thanks, I'll fix it.
> 
>> 
>>> +else
>>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>> +break;
>>> +
>>> +case FFA_NOTIFICATION_BIND:
>>> +case FFA_NOTIFICATION_UNBIND:
>>> +case FFA_NOTIFICATION_GET:
>>> +case FFA_NOTIFICATION_SET:
>>> +case FFA_NOTIFICATION_INFO_GET_32:
>>> +case FFA_NOTIFICATION_INFO_GET_64:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, 0, 0);
>>> +else
>>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>> +break;
>>>default:
>>>ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>>break;
>>> @@ -305,6 +334,30 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
>>> get_user_reg(regs, 1)),
>>>   get_user_reg(regs, 3));
>>>break;
>>> +case FFA_NOTIFICATION_BIND:
>>> +e = ffa_handle_notification_bind(get_user_reg(regs, 1),
>>> + get_user_reg(regs, 2),
>>> + get_user_reg(regs, 3),
>>> + 

Re: [XEN PATCH v1 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 10 Apr 2024, at 16:27, Jens Wiklander  wrote:
> 
> On Wed, Apr 10, 2024 at 9:49 AM Bertrand Marquis
>  wrote:
>> 
>> Hi Jens,
>> 
>>> On 9 Apr 2024, at 17:36, Jens Wiklander  wrote:
>>> 
>>> Add support for FF-A notifications, currently limited to an SP (Secure
>>> Partition) sending an asynchronous notification to a guest.
>>> 
>>> Guests and Xen itself are made aware of pending notifications with an
>>> interrupt. The interrupt handler retrieves the notifications using the
>>> FF-A ABI and deliver them to their destinations.
>>> 
>>> Signed-off-by: Jens Wiklander 
>>> ---
>>> xen/arch/arm/tee/Makefile  |   1 +
>>> xen/arch/arm/tee/ffa.c |  58 ++
>>> xen/arch/arm/tee/ffa_notif.c   | 319 +
>>> xen/arch/arm/tee/ffa_private.h |  71 
>>> 4 files changed, 449 insertions(+)
>>> create mode 100644 xen/arch/arm/tee/ffa_notif.c
>>> 
>>> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
>>> index f0112a2f922d..7c0f46f7f446 100644
>>> --- a/xen/arch/arm/tee/Makefile
>>> +++ b/xen/arch/arm/tee/Makefile
>>> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
>>> obj-$(CONFIG_FFA) += ffa_shm.o
>>> obj-$(CONFIG_FFA) += ffa_partinfo.o
>>> obj-$(CONFIG_FFA) += ffa_rxtx.o
>>> +obj-$(CONFIG_FFA) += ffa_notif.o
>>> obj-y += tee.o
>>> obj-$(CONFIG_OPTEE) += optee.o
>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>>> index 5209612963e1..ce9757bfeed1 100644
>>> --- a/xen/arch/arm/tee/ffa.c
>>> +++ b/xen/arch/arm/tee/ffa.c
>>> @@ -39,6 +39,9 @@
>>> *   - at most 32 shared memory regions per guest
>>> * o FFA_MSG_SEND_DIRECT_REQ:
>>> *   - only supported from a VM to an SP
>>> + * o FFA_NOTIFICATION_*:
>>> + *   - only supports global notifications, that is, per vCPU notifications
>>> + * are not supported
>>> *
>>> * There are some large locked sections with ffa_tx_buffer_lock and
>>> * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
>>> @@ -194,6 +197,8 @@ out:
>>> 
>>> static void handle_features(struct cpu_user_regs *regs)
>>> {
>>> +struct domain *d = current->domain;
>>> +struct ffa_ctx *ctx = d->arch.tee;
>>>uint32_t a1 = get_user_reg(regs, 1);
>>>unsigned int n;
>>> 
>>> @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
>>>BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
>>>ffa_set_regs_success(regs, 0, 0);
>>>break;
>>> +case FFA_FEATURE_NOTIF_PEND_INTR:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>>> +else
>>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>> +break;
>>> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
>> 
>> This should return the RECV_INTR, not the PEND one.
> 
> Thanks, I'll fix it.
> 
>> 
>>> +else
>>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>> +break;
>>> +
>>> +case FFA_NOTIFICATION_BIND:
>>> +case FFA_NOTIFICATION_UNBIND:
>>> +case FFA_NOTIFICATION_GET:
>>> +case FFA_NOTIFICATION_SET:
>>> +case FFA_NOTIFICATION_INFO_GET_32:
>>> +case FFA_NOTIFICATION_INFO_GET_64:
>>> +if ( ctx->notif.enabled )
>>> +ffa_set_regs_success(regs, 0, 0);
>>> +else
>>> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>> +break;
>>>default:
>>>ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
>>>break;
>>> @@ -305,6 +334,30 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
>>> get_user_reg(regs, 1)),
>>>   get_user_reg(regs, 3));
>>>break;
>>> +case FFA_NOTIFICATION_BIND:
>>> +e = ffa_handle_notification_bind(get_user_reg(regs, 1),
>>> + get_user_reg(regs, 2),
>>> + get_user_reg(regs, 3),
>>> + 

Re: [XEN PATCH v1 5/5] xen/arm: ffa: support notification

[Bertrand Marquis]

Hi Jens,

> On 9 Apr 2024, at 17:36, Jens Wiklander  wrote:
> 
> Add support for FF-A notifications, currently limited to an SP (Secure
> Partition) sending an asynchronous notification to a guest.
> 
> Guests and Xen itself are made aware of pending notifications with an
> interrupt. The interrupt handler retrieves the notifications using the
> FF-A ABI and deliver them to their destinations.
> 
> Signed-off-by: Jens Wiklander 
> ---
> xen/arch/arm/tee/Makefile  |   1 +
> xen/arch/arm/tee/ffa.c |  58 ++
> xen/arch/arm/tee/ffa_notif.c   | 319 +
> xen/arch/arm/tee/ffa_private.h |  71 
> 4 files changed, 449 insertions(+)
> create mode 100644 xen/arch/arm/tee/ffa_notif.c
> 
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index f0112a2f922d..7c0f46f7f446 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -2,5 +2,6 @@ obj-$(CONFIG_FFA) += ffa.o
> obj-$(CONFIG_FFA) += ffa_shm.o
> obj-$(CONFIG_FFA) += ffa_partinfo.o
> obj-$(CONFIG_FFA) += ffa_rxtx.o
> +obj-$(CONFIG_FFA) += ffa_notif.o
> obj-y += tee.o
> obj-$(CONFIG_OPTEE) += optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 5209612963e1..ce9757bfeed1 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -39,6 +39,9 @@
>  *   - at most 32 shared memory regions per guest
>  * o FFA_MSG_SEND_DIRECT_REQ:
>  *   - only supported from a VM to an SP
> + * o FFA_NOTIFICATION_*:
> + *   - only supports global notifications, that is, per vCPU notifications
> + * are not supported
>  *
>  * There are some large locked sections with ffa_tx_buffer_lock and
>  * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
> @@ -194,6 +197,8 @@ out:
> 
> static void handle_features(struct cpu_user_regs *regs)
> {
> +struct domain *d = current->domain;
> +struct ffa_ctx *ctx = d->arch.tee;
> uint32_t a1 = get_user_reg(regs, 1);
> unsigned int n;
> 
> @@ -240,6 +245,30 @@ static void handle_features(struct cpu_user_regs *regs)
> BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
> ffa_set_regs_success(regs, 0, 0);
> break;
> +case FFA_FEATURE_NOTIF_PEND_INTR:
> +if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);
> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> +case FFA_FEATURE_SCHEDULE_RECV_INTR:
> +if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, FFA_NOTIF_PEND_INTR_ID, 0);

This should return the RECV_INTR, not the PEND one.

> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> +
> +case FFA_NOTIFICATION_BIND:
> +case FFA_NOTIFICATION_UNBIND:
> +case FFA_NOTIFICATION_GET:
> +case FFA_NOTIFICATION_SET:
> +case FFA_NOTIFICATION_INFO_GET_32:
> +case FFA_NOTIFICATION_INFO_GET_64:
> +if ( ctx->notif.enabled )
> +ffa_set_regs_success(regs, 0, 0);
> +else
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> default:
> ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> break;
> @@ -305,6 +334,30 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
>  get_user_reg(regs, 1)),
>get_user_reg(regs, 3));
> break;
> +case FFA_NOTIFICATION_BIND:
> +e = ffa_handle_notification_bind(get_user_reg(regs, 1),
> + get_user_reg(regs, 2),
> + get_user_reg(regs, 3),
> + get_user_reg(regs, 4));

I would suggest to pass regs and handle the get_user_regs in the function.

> +break;
> +case FFA_NOTIFICATION_UNBIND:
> +e = ffa_handle_notification_unbind(get_user_reg(regs, 1),
> +   get_user_reg(regs, 3),
> +   get_user_reg(regs, 4));

same here

> +break;
> +case FFA_NOTIFICATION_INFO_GET_32:
> +case FFA_NOTIFICATION_INFO_GET_64:
> +ffa_handle_notification_info_get(regs);
> +return true;
> +case FFA_NOTIFICATION_GET:
> +ffa_handle_notification_get(regs);
> +return true;
> +case FFA_NOTIFICATION_SET:
> +e = ffa_handle_notification_set(get_user_reg(regs, 1),
> +get_user_reg(regs, 2),
> +get_user_reg(regs, 3),
> +get_user_reg(regs, 4));

same here

> +break;
> 
> default:
> gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
> @@ -348,6 +401,9 @@ static int ffa_domain_init(struct domain *d)
> if ( !ffa_partinfo_domain_init(d) )
> return -EIO;
> 
> +if ( !ffa_notif_domain_init(d) )
> 

Re: [XEN PATCH v1 3/5] xen/arm: ffa: simplify ffa_handle_mem_share()

[Bertrand Marquis]

Hi Jens,

> On 9 Apr 2024, at 17:36, Jens Wiklander  wrote:
> 
> Simplify ffa_handle_mem_share() by removing the start_page_idx and
> last_page_idx parameters from get_shm_pages() and check that the number
> of pages matches expectations at the end of get_shm_pages().
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa_shm.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c
> index 75a5b66aeb4c..370d83ec5cf8 100644
> --- a/xen/arch/arm/tee/ffa_shm.c
> +++ b/xen/arch/arm/tee/ffa_shm.c
> @@ -159,10 +159,9 @@ static int32_t ffa_mem_reclaim(uint32_t handle_lo, 
> uint32_t handle_hi,
>  */
> static int get_shm_pages(struct domain *d, struct ffa_shm_mem *shm,
>  const struct ffa_address_range *range,
> - uint32_t range_count, unsigned int start_page_idx,
> - unsigned int *last_page_idx)
> + uint32_t range_count)
> {
> -unsigned int pg_idx = start_page_idx;
> +unsigned int pg_idx = 0;
> gfn_t gfn;
> unsigned int n;
> unsigned int m;
> @@ -191,7 +190,9 @@ static int get_shm_pages(struct domain *d, struct 
> ffa_shm_mem *shm,
> }
> }
> 
> -*last_page_idx = pg_idx;
> +/* The ranges must add up */
> +if ( pg_idx < shm->page_count )
> +return FFA_RET_INVALID_PARAMETERS;
> 
> return FFA_RET_OK;
> }
> @@ -460,7 +461,6 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs)
> struct domain *d = current->domain;
> struct ffa_ctx *ctx = d->arch.tee;
> struct ffa_shm_mem *shm = NULL;
> -unsigned int last_page_idx = 0;
> register_t handle_hi = 0;
> register_t handle_lo = 0;
> int ret = FFA_RET_DENIED;
> @@ -570,15 +570,9 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs)
> goto out;
> }
> 
> -ret = get_shm_pages(d, shm, region_descr->address_range_array, 
> range_count,
> -0, _page_idx);
> +ret = get_shm_pages(d, shm, region_descr->address_range_array, 
> range_count);
> if ( ret )
> goto out;
> -if ( last_page_idx != shm->page_count )
> -{
> -ret = FFA_RET_INVALID_PARAMETERS;
> -goto out;
> -}
> 
> /* Note that share_shm() uses our tx buffer */
> spin_lock(_tx_buffer_lock);
> -- 
> 2.34.1
> 

Re: [XEN PATCH v1 2/5] xen/arm: ffa: use ACCESS_ONCE()

[Bertrand Marquis]

Hi Jens,

> On 9 Apr 2024, at 17:36, Jens Wiklander  wrote:
> 
> Replace read_atomic() with ACCESS_ONCE() to match the intended use, that
> is, to prevent the compiler from (via optimization) reading shared
> memory more than once.

This definitely makes sense.

> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa_shm.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa_shm.c b/xen/arch/arm/tee/ffa_shm.c
> index eed9ad2d2986..75a5b66aeb4c 100644
> --- a/xen/arch/arm/tee/ffa_shm.c
> +++ b/xen/arch/arm/tee/ffa_shm.c
> @@ -7,6 +7,7 @@
> #include 
> #include 
> #include 
> +#include 
> #include 
> #include 
> 
> @@ -171,8 +172,8 @@ static int get_shm_pages(struct domain *d, struct 
> ffa_shm_mem *shm,
> 
> for ( n = 0; n < range_count; n++ )
> {
> -page_count = read_atomic([n].page_count);
> -addr = read_atomic([n].address);
> +page_count = ACCESS_ONCE(range[n].page_count);
> +addr = ACCESS_ONCE(range[n].address);
> for ( m = 0; m < page_count; m++ )
> {
> if ( pg_idx >= shm->page_count )
> @@ -527,13 +528,13 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs)
> goto out_unlock;
> 
> mem_access = ctx->tx + trans.mem_access_offs;
> -if ( read_atomic(_access->access_perm.perm) != FFA_MEM_ACC_RW )
> +if ( ACCESS_ONCE(mem_access->access_perm.perm) != FFA_MEM_ACC_RW )
> {
> ret = FFA_RET_NOT_SUPPORTED;
> goto out_unlock;
> }
> 
> -region_offs = read_atomic(_access->region_offs);
> +region_offs = ACCESS_ONCE(mem_access->region_offs);
> if ( sizeof(*region_descr) + region_offs > frag_len )
> {
> ret = FFA_RET_NOT_SUPPORTED;
> @@ -541,8 +542,8 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs)
> }
> 
> region_descr = ctx->tx + region_offs;
> -range_count = read_atomic(_descr->address_range_count);
> -page_count = read_atomic(_descr->total_page_count);
> +range_count = ACCESS_ONCE(region_descr->address_range_count);
> +page_count = ACCESS_ONCE(region_descr->total_page_count);
> 
> if ( !page_count )
> {
> @@ -557,7 +558,7 @@ void ffa_handle_mem_share(struct cpu_user_regs *regs)
> goto out_unlock;
> }
> shm->sender_id = trans.sender_id;
> -shm->ep_id = read_atomic(_access->access_perm.endpoint_id);
> +shm->ep_id = ACCESS_ONCE(mem_access->access_perm.endpoint_id);
> 
> /*
>  * Check that the Composite memory region descriptor fits.
> -- 
> 2.34.1
> 

Re: [XEN PATCH v1 1/5] xen/arm: ffa: refactor ffa_handle_call()

[Bertrand Marquis]

Hi Jens,

> On 9 Apr 2024, at 17:36, Jens Wiklander  wrote:
> 
> Refactors the large switch block in ffa_handle_call() to use common code
> for the simple case where it's either an error code or success with no
> further parameters.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 30 ++
> 1 file changed, 10 insertions(+), 20 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 8665201e34a9..5209612963e1 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -273,18 +273,10 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> case FFA_RXTX_MAP_64:
> e = ffa_handle_rxtx_map(fid, get_user_reg(regs, 1),
> get_user_reg(regs, 2), get_user_reg(regs, 3));
> -if ( e )
> -ffa_set_regs_error(regs, e);
> -else
> -ffa_set_regs_success(regs, 0, 0);
> -return true;
> +break;
> case FFA_RXTX_UNMAP:
> e = ffa_handle_rxtx_unmap();
> -if ( e )
> -ffa_set_regs_error(regs, e);
> -else
> -ffa_set_regs_success(regs, 0, 0);
> -return true;
> +break;
> case FFA_PARTITION_INFO_GET:
> e = ffa_handle_partition_info_get(get_user_reg(regs, 1),
>   get_user_reg(regs, 2),
> @@ -299,11 +291,7 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> return true;
> case FFA_RX_RELEASE:
> e = ffa_handle_rx_release();
> -if ( e )
> -ffa_set_regs_error(regs, e);
> -else
> -ffa_set_regs_success(regs, 0, 0);
> -return true;
> +break;
> case FFA_MSG_SEND_DIRECT_REQ_32:
> case FFA_MSG_SEND_DIRECT_REQ_64:
> handle_msg_send_direct_req(regs, fid);
> @@ -316,17 +304,19 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> e = ffa_handle_mem_reclaim(regpair_to_uint64(get_user_reg(regs, 2),
>  get_user_reg(regs, 1)),
>get_user_reg(regs, 3));
> -if ( e )
> -ffa_set_regs_error(regs, e);
> -else
> -ffa_set_regs_success(regs, 0, 0);
> -return true;
> +break;
> 
> default:
> gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
> ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> return true;
> }
> +
> +if ( e )
> +ffa_set_regs_error(regs, e);
> +else
> +ffa_set_regs_success(regs, 0, 0);
> +return true;
> }
> 
> static int ffa_domain_init(struct domain *d)
> -- 
> 2.34.1
> 

Re: [PATCH v4] docs/misra: document the expected sizes of integer types

[Bertrand Marquis]

Hi Stefano,

> On 5 Apr 2024, at 20:44, Stefano Stabellini  wrote:
> 
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.
> 
> Signed-off-by: Stefano Stabellini 

I think it is a good start and definitely better than having nothing documented 
so:

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes in v4:
> - list the architectures explicitly
> - add ARMv7-A
> ---
> docs/misra/C-language-toolchain.rst | 73 +
> 1 file changed, 73 insertions(+)
> 
> diff --git a/docs/misra/C-language-toolchain.rst 
> b/docs/misra/C-language-toolchain.rst
> index b7c2000992..5ddfe7bdbe 100644
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -480,4 +480,77 @@ The table columns are as follows:
>  - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section 
> "11.1 Implementation-defined behavior" of CPP_MANUAL.
> 
> 
> +Sizes of Integer types
> +__
> +
> +Xen expects System V ABI on x86_64:
> +  https://gitlab.com/x86-psABIs/x86-64-ABI
> +
> +Xen expects AAPCS32 on ARMv8-A AArch32 and ARMv7-A:
> +  https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
> +
> +Xen expects AAPCS64 LP64 on ARMv8-A AArch64:
> +  https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
> +
> +A summary table of data types, sizes and alignment is below:
> +
> +.. list-table::
> +   :widths: 10 10 10 45
> +   :header-rows: 1
> +
> +   * - Type
> + - Size
> + - Alignment
> + - Architectures
> +
> +   * - char 
> + - 8 bits
> + - 8 bits
> + - x86_32, ARMv8-A AArch32, ARMv8-R AArch32, ARMv7-A, x86_64,
> +   ARMv8-A AArch64, RV64, PPC64
> +
> +   * - short
> + - 16 bits
> + - 16 bits
> + - x86_32, ARMv8-A AArch32, ARMv8-R AArch32, ARMv7-A, x86_64,
> +   ARMv8-A AArch64, RV64, PPC64
> +
> +   * - int
> + - 32 bits
> + - 32 bits
> + - x86_32, ARMv8-A AArch32, ARMv8-R AArch32, ARMv7-A, x86_64,
> +   ARMv8-A AArch64, RV64, PPC64
> +
> +   * - long
> + - 32 bits
> + - 32 bits 
> + - x86_32, ARMv8-A AArch32, ARMv8-R AArch32, ARMv7-A
> +
> +   * - long
> + - 64 bits
> + - 64 bits 
> + - x86_64, ARMv8-A AArch64, RV64, PPC64
> +
> +   * - long long
> + - 64-bit
> + - 32-bit
> + - x86_32
> +
> +   * - long long
> + - 64-bit
> + - 64-bit
> + - x86_64, ARMv8-A AArch64, RV64, PPC64, ARMv8-A AArch32, ARMv8-R
> +   AArch32, ARMv7-A
> +
> +   * - pointer
> + - 32-bit
> + - 32-bit
> + - x86_32, ARMv8-A AArch32, ARMv8-R AArch32, ARMv7-A
> +
> +   * - pointer
> + - 64-bit
> + - 64-bit
> + - x86_64, ARMv8-A AArch64, RV64, PPC64
> +
> +
> END OF DOCUMENT.
> -- 
> 2.25.1
> 

Re: [PATCH v3] docs/misra: document the expected sizes of integer types

[Bertrand Marquis]

Hi Stefano,

> On 5 Apr 2024, at 01:57, Stefano Stabellini  wrote:
> 
> On Thu, 4 Apr 2024, Bertrand Marquis wrote:
>> Hi Stefano,
>> 
>>> On 4 Apr 2024, at 03:12, Stefano Stabellini  wrote:
>>> 
>>> Xen makes assumptions about the size of integer types on the various
>>> architectures. Document these assumptions.
>>> 
>>> Signed-off-by: Stefano Stabellini 
>>> ---
>>> Changes in v3:
>>> - add links to System V, AAPCS32 and AAPCS64
>>> 
>>> ---
>>> docs/misra/C-language-toolchain.rst | 69 +
>>> 1 file changed, 69 insertions(+)
>>> 
>>> diff --git a/docs/misra/C-language-toolchain.rst 
>>> b/docs/misra/C-language-toolchain.rst
>>> index b7c2000992..84b21992bc 100644
>>> --- a/docs/misra/C-language-toolchain.rst
>>> +++ b/docs/misra/C-language-toolchain.rst
>>> @@ -480,4 +480,73 @@ The table columns are as follows:
>>> - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section 
>>> "11.1 Implementation-defined behavior" of CPP_MANUAL.
>>> 
>>> 
>>> +Sizes of Integer types
>>> +__
>>> +
>>> +Xen expects System V ABI on x86_64:
>>> +  https://gitlab.com/x86-psABIs/x86-64-ABI
>>> +
>>> +Xen expects AAPCS32 on ARMv8-A AArch32:
>>> +  https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
>>> +
>>> +Xen expects AAPCS64 LP64 on ARMv8-A AArch64:
>>> +  https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
>> 
>> We still support armv7 somehow so we should add something for it here.
>> 
>>> +
>>> +A summary table of data types, sizes and alignment is below:
>>> +
>>> +.. list-table::
>>> +   :widths: 10 10 10 45
>>> +   :header-rows: 1
>>> +
>>> +   * - Type
>>> + - Size
>>> + - Alignment
>>> + - Architectures
>>> +
>>> +   * - char 
>>> + - 8 bits
>>> + - 8 bits
>>> + - all architectures
>>> +
>>> +   * - short
>>> + - 16 bits
>>> + - 16 bits
>>> + - all architectures
>>> +
>>> +   * - int
>>> + - 32 bits
>>> + - 32 bits
>>> + - all architectures
>>> +
>>> +   * - long
>>> + - 32 bits
>>> + - 32 bits 
>>> + - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
>> 
>> Same here armv7 should be mentioned.
>> 
>>> +
>>> +   * - long
>>> + - 64 bits
>>> + - 64 bits 
>>> + - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
>>> +
>>> +   * - long long
>>> + - 64-bit
>>> + - 32-bit
>>> + - x86_32
>>> +
>>> +   * - long long
>>> + - 64-bit
>>> + - 64-bit
>>> + - 64-bit architectures, ARMv8-A AArch32, ARMv8-R AArch32
>> 
>> Should this be all architecture except x86_32 ?
> 
> yes
> 
>>> +
>>> +   * - pointer
>>> + - 32-bit
>>> + - 32-bit
>>> + - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
>> 
>> Armv7 missing here.
> 
> What is the formal name I should use for it here? ARMv7 AArch32 ?

Armv7-A (no need to specify anything more as it was 32bit only).

Cheers
Bertrand

Re: [PATCH v3] docs/misra: document the expected sizes of integer types

[Bertrand Marquis]

Hi Stefano,

> On 4 Apr 2024, at 03:12, Stefano Stabellini  wrote:
> 
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.
> 
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v3:
> - add links to System V, AAPCS32 and AAPCS64
> 
> ---
> docs/misra/C-language-toolchain.rst | 69 +
> 1 file changed, 69 insertions(+)
> 
> diff --git a/docs/misra/C-language-toolchain.rst 
> b/docs/misra/C-language-toolchain.rst
> index b7c2000992..84b21992bc 100644
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -480,4 +480,73 @@ The table columns are as follows:
>  - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section 
> "11.1 Implementation-defined behavior" of CPP_MANUAL.
> 
> 
> +Sizes of Integer types
> +__
> +
> +Xen expects System V ABI on x86_64:
> +  https://gitlab.com/x86-psABIs/x86-64-ABI
> +
> +Xen expects AAPCS32 on ARMv8-A AArch32:
> +  https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
> +
> +Xen expects AAPCS64 LP64 on ARMv8-A AArch64:
> +  https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst

We still support armv7 somehow so we should add something for it here.

> +
> +A summary table of data types, sizes and alignment is below:
> +
> +.. list-table::
> +   :widths: 10 10 10 45
> +   :header-rows: 1
> +
> +   * - Type
> + - Size
> + - Alignment
> + - Architectures
> +
> +   * - char 
> + - 8 bits
> + - 8 bits
> + - all architectures
> +
> +   * - short
> + - 16 bits
> + - 16 bits
> + - all architectures
> +
> +   * - int
> + - 32 bits
> + - 32 bits
> + - all architectures
> +
> +   * - long
> + - 32 bits
> + - 32 bits 
> + - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)

Same here armv7 should be mentioned.

> +
> +   * - long
> + - 64 bits
> + - 64 bits 
> + - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
> +
> +   * - long long
> + - 64-bit
> + - 32-bit
> + - x86_32
> +
> +   * - long long
> + - 64-bit
> + - 64-bit
> + - 64-bit architectures, ARMv8-A AArch32, ARMv8-R AArch32

Should this be all architecture except x86_32 ?

> +
> +   * - pointer
> + - 32-bit
> + - 32-bit
> + - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)

Armv7 missing here.

> +
> +   * - pointer
> + - 64-bit
> + - 64-bit
> + - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
> +
> +
> END OF DOCUMENT.
> -- 
> 2.25.1
> 

Cheers
Bertrand

Re: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines

[Bertrand Marquis]

Hi Julien,

> On 28 Mar 2024, at 18:58, Julien Grall  wrote:
> 
> Hi Bertrand,
> 
> On 27/03/2024 13:40, Bertrand Marquis wrote:
>> Hi Jens,
>>> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
>>> 
>>> Move memory sharing routines into a separate file for easier navigation
>>> in the source code.
>>> 
>>> Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
>>> ffa_domain_teardown_continue().
>>> 
>>> Signed-off-by: Jens Wiklander 
>> With the copyright date mentioned after fixed (which can be done on commit):
>> Reviewed-by: Bertrand Marquis  
> I have fixed and committed the series. However, it wasn't trivial to find the 
> comment in your reply. In the future, can you try to trim your reply?

Thanks a lot and very sorry for that, I will remember to trim next time.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [XEN PATCH 0/6] FF-A mediator reorganisation

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:38, Jens Wiklander  wrote:
> 
> Hi,
> 
> The FF-A mediator is reorganized into modules for easier maintenance and to
> prepare for future changes. This patch set is not expected add any changed
> behaviour, except for the "xen/arm: ffa: support FFA_FEATURES" patch.

I reviewed the serie and there is only one tiny fix of copyright date that
can be done on commit.

Appart from that, I tested FF-A with the whole serie applied and I can
confirm it works on my side so for the whole serie:

Tested-by: Bertrand Marquis 

Cheers
Bertrand

> 
> Thanks,
> Jens
> 
> Jens Wiklander (6):
>  xen/arm: ffa: rename functions to use ffa_ prefix
>  xen/arm: ffa: move common things to ffa_private.h
>  xen/arm: ffa: separate memory sharing routines
>  xen/arm: ffa: separate partition info get routines
>  xen/arm: ffa: separate rxtx buffer routines
>  xen/arm: ffa: support FFA_FEATURES
> 
> xen/arch/arm/tee/Makefile   |3 +
> xen/arch/arm/tee/ffa.c  | 1629 ++-
> xen/arch/arm/tee/ffa_partinfo.c |  373 +++
> xen/arch/arm/tee/ffa_private.h  |  347 +++
> xen/arch/arm/tee/ffa_rxtx.c |  216 
> xen/arch/arm/tee/ffa_shm.c  |  708 ++
> 6 files changed, 1750 insertions(+), 1526 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_partinfo.c
> create mode 100644 xen/arch/arm/tee/ffa_private.h
> create mode 100644 xen/arch/arm/tee/ffa_rxtx.c
> create mode 100644 xen/arch/arm/tee/ffa_shm.c
> 
> -- 
> 2.34.1
> 

Re: [XEN PATCH 6/6] xen/arm: ffa: support FFA_FEATURES

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
> 
> Add support for the mandatory FF-A ABI function FFA_FEATURES.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 57 ++
> 1 file changed, 57 insertions(+)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 4f7775b8c890..8665201e34a9 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -192,6 +192,60 @@ out:
>  resp.a7 & mask);
> }
> 
> +static void handle_features(struct cpu_user_regs *regs)
> +{
> +uint32_t a1 = get_user_reg(regs, 1);
> +unsigned int n;
> +
> +for ( n = 2; n <= 7; n++ )
> +{
> +if ( get_user_reg(regs, n) )
> +{
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +return;
> +}
> +}
> +
> +switch ( a1 )
> +{
> +case FFA_ERROR:
> +case FFA_VERSION:
> +case FFA_SUCCESS_32:
> +case FFA_SUCCESS_64:
> +case FFA_FEATURES:
> +case FFA_ID_GET:
> +case FFA_RX_RELEASE:
> +case FFA_RXTX_UNMAP:
> +case FFA_MEM_RECLAIM:
> +case FFA_PARTITION_INFO_GET:
> +case FFA_MSG_SEND_DIRECT_REQ_32:
> +case FFA_MSG_SEND_DIRECT_REQ_64:
> +ffa_set_regs_success(regs, 0, 0);
> +break;
> +case FFA_MEM_SHARE_64:
> +case FFA_MEM_SHARE_32:
> +/*
> + * We currently don't support dynamically allocated buffers. Report
> + * that with 0 in bit[0] of w2.
> + */
> +ffa_set_regs_success(regs, 0, 0);
> +break;
> +case FFA_RXTX_MAP_64:
> +case FFA_RXTX_MAP_32:
> +/*
> + * We currently support 4k pages only, report that as 00 in
> + * bit[0:1] in w0. This needs to be revised if Xen page size
> + * differs from FFA_PAGE_SIZE (SZ_4K).
> + */
> +BUILD_BUG_ON(PAGE_SIZE != FFA_PAGE_SIZE);
> +ffa_set_regs_success(regs, 0, 0);
> +break;
> +default:
> +ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +break;
> +}
> +}
> +
> static bool ffa_handle_call(struct cpu_user_regs *regs)
> {
> uint32_t fid = get_user_reg(regs, 0);
> @@ -212,6 +266,9 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> case FFA_ID_GET:
> ffa_set_regs_success(regs, ffa_get_vm_id(d), 0);
> return true;
> +case FFA_FEATURES:
> +handle_features(regs);
> +return true;
> case FFA_RXTX_MAP_32:
> case FFA_RXTX_MAP_64:
> e = ffa_handle_rxtx_map(fid, get_user_reg(regs, 1),
> -- 
> 2.34.1
> 

Re: [XEN PATCH 5/6] xen/arm: ffa: separate rxtx buffer routines

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
> 
> Move rxtx buffer routines into a spearate file for easier navigation in
> the source code.
> 
> Add ffa_rxtx_init(), ffa_rxtx_destroy(), and ffa_rxtx_domain_destroy() to
> handle the ffa_rxtx internal things on initialization and teardown.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/Makefile  |   1 +
> xen/arch/arm/tee/ffa.c | 174 +-
> xen/arch/arm/tee/ffa_private.h |   7 ++
> xen/arch/arm/tee/ffa_rxtx.c| 216 +
> 4 files changed, 229 insertions(+), 169 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_rxtx.c
> 
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index be644fba8055..f0112a2f922d 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -1,5 +1,6 @@
> obj-$(CONFIG_FFA) += ffa.o
> obj-$(CONFIG_FFA) += ffa_shm.o
> obj-$(CONFIG_FFA) += ffa_partinfo.o
> +obj-$(CONFIG_FFA) += ffa_rxtx.o
> obj-y += tee.o
> obj-$(CONFIG_OPTEE) += optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 7a2803881420..4f7775b8c890 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -65,26 +65,6 @@
> 
> #include "ffa_private.h"
> 
> -/*
> - * Structs below ending with _1_0 are defined in FF-A-1.0-REL and
> - * structs ending with _1_1 are defined in FF-A-1.1-REL0.
> - */
> -
> -/* Endpoint RX/TX descriptor */
> -struct ffa_endpoint_rxtx_descriptor_1_0 {
> -uint16_t sender_id;
> -uint16_t reserved;
> -uint32_t rx_range_count;
> -uint32_t tx_range_count;
> -};
> -
> -struct ffa_endpoint_rxtx_descriptor_1_1 {
> -uint16_t sender_id;
> -uint16_t reserved;
> -uint32_t rx_region_offs;
> -uint32_t tx_region_offs;
> -};
> -
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_after_init ffa_version;
> 
> @@ -145,12 +125,6 @@ static bool check_mandatory_feature(uint32_t id)
> return !ret;
> }
> 
> -static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t rx_addr,
> -uint32_t page_count)
> -{
> -return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count, 0);
> -}
> -
> static void handle_version(struct cpu_user_regs *regs)
> {
> struct domain *d = current->domain;
> @@ -166,127 +140,6 @@ static void handle_version(struct cpu_user_regs *regs)
> ffa_set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> }
> 
> -static uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
> -register_t rx_addr, uint32_t page_count)
> -{
> -uint32_t ret = FFA_RET_INVALID_PARAMETERS;
> -struct domain *d = current->domain;
> -struct ffa_ctx *ctx = d->arch.tee;
> -struct page_info *tx_pg;
> -struct page_info *rx_pg;
> -p2m_type_t t;
> -void *rx;
> -void *tx;
> -
> -if ( !smccc_is_conv_64(fid) )
> -{
> -/*
> - * Calls using the 32-bit calling convention must ignore the upper
> - * 32 bits in the argument registers.
> - */
> -tx_addr &= UINT32_MAX;
> -rx_addr &= UINT32_MAX;
> -}
> -
> -if ( page_count > FFA_MAX_RXTX_PAGE_COUNT )
> -{
> -printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (limit 
> %u)\n",
> -   page_count, FFA_MAX_RXTX_PAGE_COUNT);
> -return FFA_RET_INVALID_PARAMETERS;
> -}
> -
> -/* Already mapped */
> -if ( ctx->rx )
> -return FFA_RET_DENIED;
> -
> -tx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(tx_addr)), , 
> P2M_ALLOC);
> -if ( !tx_pg )
> -return FFA_RET_INVALID_PARAMETERS;
> -
> -/* Only normal RW RAM for now */
> -if ( t != p2m_ram_rw )
> -goto err_put_tx_pg;
> -
> -rx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), , 
> P2M_ALLOC);
> -if ( !tx_pg )
> -goto err_put_tx_pg;
> -
> -/* Only normal RW RAM for now */
> -if ( t != p2m_ram_rw )
> -goto err_put_rx_pg;
> -
> -tx = __map_domain_page_global(tx_pg);
> -if ( !tx )
> -goto err_put_rx_pg;
> -
> -rx = __map_domain_page_global(rx_pg);
> -if ( !rx )
> -goto err_unmap_tx;
> -
> -ctx->rx = rx;
> -ctx->tx = tx;
> -ctx->rx_pg = rx_pg;
> -ctx->tx_pg = tx_pg;
> -ctx->page_count = page_count;
> -ctx->rx_is_free = true;
> -return FFA_RET_OK;
> -
> -err_unmap_tx:
> -unmap_domain_page_global(tx);
> -err_put_rx_pg:
&g

Re: [XEN PATCH 4/6] xen/arm: ffa: separate partition info get routines

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
> 
> Move partition info get routines into a separate file for easier
> navigation in the source code.
> 
> Add ffa_partinfo_init(), ffa_partinfo_domain_init(), and
> ffa_partinfo_domain_destroy() to handle the ffa_partinfo internal things
> on initialization and teardown.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/Makefile   |   1 +
> xen/arch/arm/tee/ffa.c  | 359 +-
> xen/arch/arm/tee/ffa_partinfo.c | 373 
> xen/arch/arm/tee/ffa_private.h  |  14 +-
> 4 files changed, 398 insertions(+), 349 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_partinfo.c
> 
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index 0e683d23aa9d..be644fba8055 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -1,4 +1,5 @@
> obj-$(CONFIG_FFA) += ffa.o
> obj-$(CONFIG_FFA) += ffa_shm.o
> +obj-$(CONFIG_FFA) += ffa_partinfo.o
> obj-y += tee.o
> obj-$(CONFIG_OPTEE) += optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index db36292dc52f..7a2803881420 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -70,20 +70,6 @@
>  * structs ending with _1_1 are defined in FF-A-1.1-REL0.
>  */
> 
> -/* Partition information descriptor */
> -struct ffa_partition_info_1_0 {
> -uint16_t id;
> -uint16_t execution_context;
> -uint32_t partition_properties;
> -};
> -
> -struct ffa_partition_info_1_1 {
> -uint16_t id;
> -uint16_t execution_context;
> -uint32_t partition_properties;
> -uint8_t uuid[16];
> -};
> -
> /* Endpoint RX/TX descriptor */
> struct ffa_endpoint_rxtx_descriptor_1_0 {
> uint16_t sender_id;
> @@ -102,11 +88,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_after_init ffa_version;
> 
> -/* SPs subscribing to VM_CREATE and VM_DESTROYED events */
> -static uint16_t *subscr_vm_created __read_mostly;
> -static uint16_t subscr_vm_created_count __read_mostly;
> -static uint16_t *subscr_vm_destroyed __read_mostly;
> -static uint16_t subscr_vm_destroyed_count __read_mostly;
> 
> /*
>  * Our rx/tx buffers shared with the SPMC. FFA_RXTX_PAGE_COUNT is the
> @@ -170,90 +151,6 @@ static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t 
> rx_addr,
> return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count, 0);
> }
> 
> -static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
> -  uint32_t w4, uint32_t w5,
> -  uint32_t *count, uint32_t *fpi_size)
> -{
> -const struct arm_smccc_1_2_regs arg = {
> -.a0 = FFA_PARTITION_INFO_GET,
> -.a1 = w1,
> -.a2 = w2,
> -.a3 = w3,
> -.a4 = w4,
> -.a5 = w5,
> -};
> -struct arm_smccc_1_2_regs resp;
> -uint32_t ret;
> -
> -arm_smccc_1_2_smc(, );
> -
> -ret = ffa_get_ret_code();
> -if ( !ret )
> -{
> -*count = resp.a2;
> -*fpi_size = resp.a3;
> -}
> -
> -return ret;
> -}
> -
> -static int32_t ffa_rx_release(void)
> -{
> -return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
> -}
> -
> -static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
> -  uint8_t msg)
> -{
> -uint32_t exp_resp = FFA_MSG_FLAG_FRAMEWORK;
> -unsigned int retry_count = 0;
> -int32_t res;
> -
> -if ( msg == FFA_MSG_SEND_VM_CREATED )
> -exp_resp |= FFA_MSG_RESP_VM_CREATED;
> -else if ( msg == FFA_MSG_SEND_VM_DESTROYED )
> -exp_resp |= FFA_MSG_RESP_VM_DESTROYED;
> -else
> -return FFA_RET_INVALID_PARAMETERS;
> -
> -do {
> -const struct arm_smccc_1_2_regs arg = {
> -.a0 = FFA_MSG_SEND_DIRECT_REQ_32,
> -.a1 = sp_id,
> -.a2 = FFA_MSG_FLAG_FRAMEWORK | msg,
> -.a5 = vm_id,
> -};
> -struct arm_smccc_1_2_regs resp;
> -
> -arm_smccc_1_2_smc(, );
> -if ( resp.a0 != FFA_MSG_SEND_DIRECT_RESP_32 || resp.a2 != exp_resp )
> -{
> -/*
> - * This is an invalid response, likely due to some error in the
> - * implementation of the ABI.
> - */
> -return FFA_RET_INVALID_PARAMETERS;
> -}
> -res = resp.a3;
> -if ( ++retry_count > 10 )
> -{
> -/*
> -

Re: [XEN PATCH 3/6] xen/arm: ffa: separate memory sharing routines

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
> 
> Move memory sharing routines into a separate file for easier navigation
> in the source code.
> 
> Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
> ffa_domain_teardown_continue().
> 
> Signed-off-by: Jens Wiklander 

With the copyright date mentioned after fixed (which can be done on commit):
Reviewed-by: Bertrand Marquis  ---
> xen/arch/arm/tee/Makefile  |   1 +
> xen/arch/arm/tee/ffa.c | 708 +
> xen/arch/arm/tee/ffa_private.h |  10 +
> xen/arch/arm/tee/ffa_shm.c | 708 +
> 4 files changed, 729 insertions(+), 698 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_shm.c
> 
> diff --git a/xen/arch/arm/tee/Makefile b/xen/arch/arm/tee/Makefile
> index 58a1015e40e0..0e683d23aa9d 100644
> --- a/xen/arch/arm/tee/Makefile
> +++ b/xen/arch/arm/tee/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_FFA) += ffa.o
> +obj-$(CONFIG_FFA) += ffa_shm.o
> obj-y += tee.o
> obj-$(CONFIG_OPTEE) += optee.o
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 259851f20bdb..db36292dc52f 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -84,92 +84,6 @@ struct ffa_partition_info_1_1 {
> uint8_t uuid[16];
> };
> 
> -/* Constituent memory region descriptor */
> -struct ffa_address_range {
> -uint64_t address;
> -uint32_t page_count;
> -uint32_t reserved;
> -};
> -
> -/* Composite memory region descriptor */
> -struct ffa_mem_region {
> -uint32_t total_page_count;
> -uint32_t address_range_count;
> -uint64_t reserved;
> -struct ffa_address_range address_range_array[];
> -};
> -
> -/* Memory access permissions descriptor */
> -struct ffa_mem_access_perm {
> -uint16_t endpoint_id;
> -uint8_t perm;
> -uint8_t flags;
> -};
> -
> -/* Endpoint memory access descriptor */
> -struct ffa_mem_access {
> -struct ffa_mem_access_perm access_perm;
> -uint32_t region_offs;
> -uint64_t reserved;
> -};
> -
> -/* Lend, donate or share memory transaction descriptor */
> -struct ffa_mem_transaction_1_0 {
> -uint16_t sender_id;
> -uint8_t mem_reg_attr;
> -uint8_t reserved0;
> -uint32_t flags;
> -uint64_t handle;
> -uint64_t tag;
> -uint32_t reserved1;
> -uint32_t mem_access_count;
> -struct ffa_mem_access mem_access_array[];
> -};
> -
> -struct ffa_mem_transaction_1_1 {
> -uint16_t sender_id;
> -uint16_t mem_reg_attr;
> -uint32_t flags;
> -uint64_t handle;
> -uint64_t tag;
> -uint32_t mem_access_size;
> -uint32_t mem_access_count;
> -uint32_t mem_access_offs;
> -uint8_t reserved[12];
> -};
> -
> -/* Calculate offset of struct ffa_mem_access from start of buffer */
> -#define MEM_ACCESS_OFFSET(access_idx) \
> -( sizeof(struct ffa_mem_transaction_1_1) + \
> -  ( access_idx ) * sizeof(struct ffa_mem_access) )
> -
> -/* Calculate offset of struct ffa_mem_region from start of buffer */
> -#define REGION_OFFSET(access_count, region_idx) \
> -( MEM_ACCESS_OFFSET(access_count) + \
> -  ( region_idx ) * sizeof(struct ffa_mem_region) )
> -
> -/* Calculate offset of struct ffa_address_range from start of buffer */
> -#define ADDR_RANGE_OFFSET(access_count, region_count, range_idx) \
> -( REGION_OFFSET(access_count, region_count) + \
> -  ( range_idx ) * sizeof(struct ffa_address_range) )
> -
> -/*
> - * The parts needed from struct ffa_mem_transaction_1_0 or struct
> - * ffa_mem_transaction_1_1, used to provide an abstraction of difference in
> - * data structures between version 1.0 and 1.1. This is just an internal
> - * interface and can be changed without changing any ABI.
> - */
> -struct ffa_mem_transaction_int {
> -uint16_t sender_id;
> -uint8_t mem_reg_attr;
> -uint8_t flags;
> -uint8_t mem_access_size;
> -uint8_t mem_access_count;
> -uint16_t mem_access_offs;
> -uint64_t handle;
> -uint64_t tag;
> -};
> -
> /* Endpoint RX/TX descriptor */
> struct ffa_endpoint_rxtx_descriptor_1_0 {
> uint16_t sender_id;
> @@ -185,15 +99,6 @@ struct ffa_endpoint_rxtx_descriptor_1_1 {
> uint32_t tx_region_offs;
> };
> 
> -struct ffa_shm_mem {
> -struct list_head list;
> -uint16_t sender_id;
> -uint16_t ep_id; /* endpoint, the one lending */
> -uint64_t handle;/* FFA_HANDLE_INVALID if not set yet */
> -unsigned int page_count;
> -struct page_info *pages[];
> -};
> -
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_

Re: [XEN PATCH 2/6] xen/arm: ffa: move common things to ffa_private.h

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:39, Jens Wiklander  wrote:
> 
> Prepare to separate ffa.c into modules by moving common things into the
> new internal header file ffa_private.h.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 298 +-
> xen/arch/arm/tee/ffa_private.h | 318 +
> 2 files changed, 319 insertions(+), 297 deletions(-)
> create mode 100644 xen/arch/arm/tee/ffa_private.h
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 0344a0f17e72..259851f20bdb 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -63,204 +63,7 @@
> #include 
> #include 
> 
> -/* Error codes */
> -#define FFA_RET_OK  0
> -#define FFA_RET_NOT_SUPPORTED   -1
> -#define FFA_RET_INVALID_PARAMETERS  -2
> -#define FFA_RET_NO_MEMORY   -3
> -#define FFA_RET_BUSY-4
> -#define FFA_RET_INTERRUPTED -5
> -#define FFA_RET_DENIED  -6
> -#define FFA_RET_RETRY   -7
> -#define FFA_RET_ABORTED -8
> -
> -/* FFA_VERSION helpers */
> -#define FFA_VERSION_MAJOR_SHIFT 16U
> -#define FFA_VERSION_MAJOR_MASK  0x7FFFU
> -#define FFA_VERSION_MINOR_SHIFT 0U
> -#define FFA_VERSION_MINOR_MASK  0xU
> -#define MAKE_FFA_VERSION(major, minor)  \
> -major) & FFA_VERSION_MAJOR_MASK) << FFA_VERSION_MAJOR_SHIFT) | \
> - ((minor) & FFA_VERSION_MINOR_MASK))
> -
> -#define FFA_VERSION_1_0 MAKE_FFA_VERSION(1, 0)
> -#define FFA_VERSION_1_1 MAKE_FFA_VERSION(1, 1)
> -/* The minimal FF-A version of the SPMC that can be supported */
> -#define FFA_MIN_SPMC_VERSIONFFA_VERSION_1_1
> -
> -/*
> - * This is the version we want to use in communication with guests and SPs.
> - * During negotiation with a guest or a SP we may need to lower it for
> - * that particular guest or SP.
> - */
> -#define FFA_MY_VERSION_MAJOR1U
> -#define FFA_MY_VERSION_MINOR1U
> -#define FFA_MY_VERSION  MAKE_FFA_VERSION(FFA_MY_VERSION_MAJOR, \
> - FFA_MY_VERSION_MINOR)
> -
> -/*
> - * The FF-A specification explicitly works with 4K pages as a measure of
> - * memory size, for example, FFA_RXTX_MAP takes one parameter "RX/TX page
> - * count" which is the number of contiguous 4K pages allocated. Xen may use
> - * a different page size depending on the configuration to avoid confusion
> - * with PAGE_SIZE use a special define when it's a page size as in the FF-A
> - * specification.
> - */
> -#define FFA_PAGE_SIZE   SZ_4K
> -
> -/*
> - * The number of pages used for each of the RX and TX buffers shared with
> - * the SPMC.
> - */
> -#define FFA_RXTX_PAGE_COUNT 1
> -
> -/*
> - * Limit the number of pages RX/TX buffers guests can map.
> - * TODO support a larger number.
> - */
> -#define FFA_MAX_RXTX_PAGE_COUNT 1
> -
> -/*
> - * Limit for shared buffer size. Please note that this define limits
> - * number of pages.
> - *
> - * FF-A doesn't have any direct requirements on GlobalPlatform or vice
> - * versa, but an implementation can very well use FF-A in order to provide
> - * a GlobalPlatform interface on top.
> - *
> - * Global Platform specification for TEE requires that any TEE
> - * implementation should allow to share buffers with size of at least
> - * 512KB, defined in TEEC-1.0C page 24, Table 4-1,
> - * TEEC_CONFIG_SHAREDMEM_MAX_SIZE.
> - * Due to overhead which can be hard to predict exactly, double this number
> - * to give a safe margin.
> - */
> -#define FFA_MAX_SHM_PAGE_COUNT  (2 * SZ_512K / FFA_PAGE_SIZE)
> -
> -/*
> - * Limits the number of shared buffers that guest can have at once. This
> - * is to prevent case, when guests trick XEN into exhausting its own
> - * memory by allocating many small buffers. This value has been chosen
> - * arbitrarily.
> - */
> -#define FFA_MAX_SHM_COUNT   32
> -
> -/*
> - * The time we wait until trying to tear down a domain again if it was
> - * blocked initially.
> - */
> -#define FFA_CTX_TEARDOWN_DELAY  SECONDS(1)
> -
> -/* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
> -#define FFA_HANDLE_HYP_FLAG BIT(63, ULL)
> -#define FFA_HANDLE_INVALID  0xULL
> -
> -/*
> - * Memory attributes: Normal memory, Write-Back cacheable, Inner shareable
> - * Defined in FF-A-1.1-REL0 Table 10.18 at page 175.
> - */
> -#define FFA_NORMAL_MEM_REG_ATTR  

Re: [XEN PATCH 1/6] xen/arm: ffa: rename functions to use ffa_ prefix

[Bertrand Marquis]

Hi Jens,

> On 25 Mar 2024, at 10:38, Jens Wiklander  wrote:
> 
> Prepare to separate into modules by renaming functions that will need
> new names when becoming non-static in the following commit.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 125 +
> 1 file changed, 65 insertions(+), 60 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 9a05dcede17a..0344a0f17e72 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -4,7 +4,7 @@
>  *
>  * Arm Firmware Framework for ARMv8-A (FF-A) mediator
>  *
> - * Copyright (C) 2023  Linaro Limited
> + * Copyright (C) 2023-2024  Linaro Limited
>  *
>  * References:
>  * FF-A-1.0-REL: FF-A specification version 1.0 available at
> @@ -473,7 +473,7 @@ static bool ffa_get_version(uint32_t *vers)
> return true;
> }
> 
> -static int32_t get_ffa_ret_code(const struct arm_smccc_1_2_regs *resp)
> +static int32_t ffa_get_ret_code(const struct arm_smccc_1_2_regs *resp)
> {
> switch ( resp->a0 )
> {
> @@ -504,7 +504,7 @@ static int32_t ffa_simple_call(uint32_t fid, register_t 
> a1, register_t a2,
> 
> arm_smccc_1_2_smc(, );
> 
> -return get_ffa_ret_code();
> +return ffa_get_ret_code();
> }
> 
> static int32_t ffa_features(uint32_t id)
> @@ -546,7 +546,7 @@ static int32_t ffa_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> 
> arm_smccc_1_2_smc(, );
> 
> -ret = get_ffa_ret_code();
> +ret = ffa_get_ret_code();
> if ( !ret )
> {
> *count = resp.a2;
> @@ -654,15 +654,16 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_id, 
> uint16_t vm_id,
> return res;
> }
> 
> -static uint16_t get_vm_id(const struct domain *d)
> +static uint16_t ffa_get_vm_id(const struct domain *d)
> {
> /* +1 since 0 is reserved for the hypervisor in FF-A */
> return d->domain_id + 1;
> }
> 
> -static void set_regs(struct cpu_user_regs *regs, register_t v0, register_t 
> v1,
> - register_t v2, register_t v3, register_t v4, register_t 
> v5,
> - register_t v6, register_t v7)
> +static void ffa_set_regs(struct cpu_user_regs *regs, register_t v0,
> + register_t v1, register_t v2, register_t v3,
> + register_t v4, register_t v5, register_t v6,
> + register_t v7)
> {
> set_user_reg(regs, 0, v0);
> set_user_reg(regs, 1, v1);
> @@ -674,15 +675,15 @@ static void set_regs(struct cpu_user_regs *regs, 
> register_t v0, register_t v1,
> set_user_reg(regs, 7, v7);
> }
> 
> -static void set_regs_error(struct cpu_user_regs *regs, uint32_t error_code)
> +static void ffa_set_regs_error(struct cpu_user_regs *regs, uint32_t 
> error_code)
> {
> -set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> +ffa_set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> }
> 
> -static void set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
> +static void ffa_set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
>  uint32_t w3)
> {
> -set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
> +ffa_set_regs(regs, FFA_SUCCESS_32, 0, w2, w3, 0, 0, 0, 0);
> }
> 
> static void handle_version(struct cpu_user_regs *regs)
> @@ -697,11 +698,11 @@ static void handle_version(struct cpu_user_regs *regs)
> vers = FFA_VERSION_1_1;
> 
> ctx->guest_vers = vers;
> -set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> +ffa_set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> }
> 
> -static uint32_t handle_rxtx_map(uint32_t fid, register_t tx_addr,
> -register_t rx_addr, uint32_t page_count)
> +static uint32_t ffa_handle_rxtx_map(uint32_t fid, register_t tx_addr,
> +register_t rx_addr, uint32_t page_count)
> {
> uint32_t ret = FFA_RET_INVALID_PARAMETERS;
> struct domain *d = current->domain;
> @@ -789,7 +790,7 @@ static void rxtx_unmap(struct ffa_ctx *ctx)
> ctx->rx_is_free = false;
> }
> 
> -static uint32_t handle_rxtx_unmap(void)
> +static uint32_t ffa_handle_rxtx_unmap(void)
> {
> struct domain *d = current->domain;
> struct ffa_ctx *ctx = d->arch.tee;
> @@ -802,9 +803,10 @@ static uint32_t handle_rxtx_unmap(void)
> return FFA_RET_OK;
> }
> 
> -static int32_t handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t 
> w3,
> - uint32_t w4, uint32_t w5,
> - uint32_t *cou

Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue

[Bertrand Marquis]

Hi John,

> On 25 Mar 2024, at 13:18, John Ernberg  wrote:
> 
> Hi Bertrand,
> 
> On 3/21/24 17:15, Bertrand Marquis wrote:
>> Hi John,
>> 
>>> On 21 Mar 2024, at 17:05, John Ernberg  wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On 3/21/24 08:41, Bertrand Marquis wrote:
>>>> Hi,
>>>> 
>>>>> On 20 Mar 2024, at 18:40, Julien Grall  wrote:
>>>>> 
>>>>> Hi John,
>>>>> 
>>>>> On 20/03/2024 16:24, John Ernberg wrote:
>>>>>> Hi Bertrand,
>>>>>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>>>>>> 
>>>>>>>> Hi John,
>>>>>>>> 
>>>>>>>> Thank you for the reply.
>>>>>>>> 
>>>>>>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>>>>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>>>>>>> Ping on the watchdog discussion bits.
>>>>>>>>>> 
>>>>>>>>>> Sorry for the late reply.
>>>>>>>>>> 
>>>>>>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>>  * IMX_SIP_TIMER_*:  This seems to be related to the watchdog.
>>>>>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So 
>>>>>>>>>>>>> those
>>>>>>>>>>>>> call will be used by Xen.
>>>>>>>>>>>> 
>>>>>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC 
>>>>>>>>>>>> internal RTC
>>>>>>>>>>>> if it is being used.
>>>>>>>>>>>> 
>>>>>>>>>>>> I looked around if there was previous discussion and only really
>>>>>>>>>>>> found [3].
>>>>>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind 
>>>>>>>>>>>> of
>>>>>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at 
>>>>>>>>>>>> the x86
>>>>>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never 
>>>>>>>>>>>> worked with
>>>>>>>>>>>> x86 nor ACPI.
>>>>>>>>>> 
>>>>>>>>>> include/watchdog.h contains helper to configure the watchdog for 
>>>>>>>>>> Xen. We
>>>>>>>>>> also have per-VM watchdog and this is configured by the hypercall
>>>>>>>>>> SCHEDOP_watchdog.
>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets 
>>>>>>>>>>>> with
>>>>>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM 
>>>>>>>>>>>> count.
>>>>>>>>>> 
>>>>>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>>>>>>>>> watchdog. So I think it would make more sense if this is not exposed 
>>>>>>>>>> to
>>>>>>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>>>>>> 
>>>>>>>>>> Can you try to hide the SMCs and check if dom0 still behave properly?
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> 
>>>>>>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>>>>>>> specific interval the entire board resets.
>>>>>>>> 
>>>>>>>> Do you know what's the default interval? Is it large enough so Xen + 
>>>>>>>> dom0 can boot (at least up to when the watchdog driver is initialized)?
>&g

Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue

[Bertrand Marquis]

Hi John,

> On 21 Mar 2024, at 17:05, John Ernberg  wrote:
> 
> Hi Bertrand,
> 
> On 3/21/24 08:41, Bertrand Marquis wrote:
>> Hi,
>> 
>>> On 20 Mar 2024, at 18:40, Julien Grall  wrote:
>>> 
>>> Hi John,
>>> 
>>> On 20/03/2024 16:24, John Ernberg wrote:
>>>> Hi Bertrand,
>>>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>>>> Hi,
>>>>> 
>>>>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>>>> 
>>>>>> Hi John,
>>>>>> 
>>>>>> Thank you for the reply.
>>>>>> 
>>>>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>>>>> Ping on the watchdog discussion bits.
>>>>>>>> 
>>>>>>>> Sorry for the late reply.
>>>>>>>> 
>>>>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>>>> 
>>>>>>>>>>>  * IMX_SIP_TIMER_*:  This seems to be related to the watchdog.
>>>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So 
>>>>>>>>>>> those
>>>>>>>>>>> call will be used by Xen.
>>>>>>>>>> 
>>>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC internal 
>>>>>>>>>> RTC
>>>>>>>>>> if it is being used.
>>>>>>>>>> 
>>>>>>>>>> I looked around if there was previous discussion and only really
>>>>>>>>>> found [3].
>>>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of
>>>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at the 
>>>>>>>>>> x86
>>>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never worked 
>>>>>>>>>> with
>>>>>>>>>> x86 nor ACPI.
>>>>>>>> 
>>>>>>>> include/watchdog.h contains helper to configure the watchdog for Xen. 
>>>>>>>> We
>>>>>>>> also have per-VM watchdog and this is configured by the hypercall
>>>>>>>> SCHEDOP_watchdog.
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets 
>>>>>>>>>> with
>>>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count.
>>>>>>>> 
>>>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>>>>>>> watchdog. So I think it would make more sense if this is not exposed to
>>>>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>>>> 
>>>>>>>> Can you try to hide the SMCs and check if dom0 still behave properly?
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> 
>>>>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>>>>> specific interval the entire board resets.
>>>>>> 
>>>>>> Do you know what's the default interval? Is it large enough so Xen + 
>>>>>> dom0 can boot (at least up to when the watchdog driver is initialized)?
>>>>>> 
>>>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the
>>>>>>> watchdog, triggering a board reset because the system looks to have
>>>>>>> become unresponsive. The reason this patch set started is because we
>>>>>>> couldn't ping the watchdog when running with Xen.
>>>>>>> In our specific system the bootloader enables the watchdog as early as
>>>>>>> possible so that we can get watchdog protection for as much of the boot
>>>>>>> as we possibly can.
>>>>>>> So, if we are to block the SMC from Dom0, then Xen needs to take over
>>>>>>> the pinging. It could be implemented similarly to the NMI watchdog,
>>>>>>> except 

Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue

[Bertrand Marquis]

Hi,

> On 20 Mar 2024, at 18:40, Julien Grall  wrote:
> 
> Hi John,
> 
> On 20/03/2024 16:24, John Ernberg wrote:
>> Hi Bertrand,
>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>> Hi,
>>> 
>>>> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
>>>> 
>>>> Hi John,
>>>> 
>>>> Thank you for the reply.
>>>> 
>>>> On 08/03/2024 13:40, John Ernberg wrote:
>>>>> On 3/7/24 00:07, Julien Grall wrote:
>>>>>>   > Ping on the watchdog discussion bits.
>>>>>> 
>>>>>> Sorry for the late reply.
>>>>>> 
>>>>>> On 06/03/2024 13:13, John Ernberg wrote:
>>>>>>> On 2/9/24 14:14, John Ernberg wrote:
>>>>>>>> 
>>>>>>>>>  * IMX_SIP_TIMER_*:  This seems to be related to the watchdog.
>>>>>>>>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those
>>>>>>>>> call will be used by Xen.
>>>>>>>> 
>>>>>>>> That is indeed a watchdog SIP, and also for setting the SoC internal 
>>>>>>>> RTC
>>>>>>>> if it is being used.
>>>>>>>> 
>>>>>>>> I looked around if there was previous discussion and only really
>>>>>>>> found [3].
>>>>>>>> Is the xen/xen/include/watchdog.h header meant to be for this kind of
>>>>>>>> watchdog support or is that more for the VM watchdog? Looking at the 
>>>>>>>> x86
>>>>>>>> ACPI NMI watchdog it seems like the former, but I have never worked 
>>>>>>>> with
>>>>>>>> x86 nor ACPI.
>>>>>> 
>>>>>> include/watchdog.h contains helper to configure the watchdog for Xen. We
>>>>>> also have per-VM watchdog and this is configured by the hypercall
>>>>>> SCHEDOP_watchdog.
>>>>>> 
>>>>>>>> 
>>>>>>>> Currently forwarding it to Dom0 has not caused any watchdog resets with
>>>>>>>> our watchdog timeout settings, our specific Dom0 setup and VM count.
>>>>>> 
>>>>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>>>>> watchdog. So I think it would make more sense if this is not exposed to
>>>>>> dom0 (even if Xen is doing nothing with it).
>>>>>> 
>>>>>> Can you try to hide the SMCs and check if dom0 still behave properly?
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>> This SMC manages a hardware watchdog, if it's not pinged within a
>>>>> specific interval the entire board resets.
>>>> 
>>>> Do you know what's the default interval? Is it large enough so Xen + dom0 
>>>> can boot (at least up to when the watchdog driver is initialized)?
>>>> 
>>>>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the
>>>>> watchdog, triggering a board reset because the system looks to have
>>>>> become unresponsive. The reason this patch set started is because we
>>>>> couldn't ping the watchdog when running with Xen.
>>>>> In our specific system the bootloader enables the watchdog as early as
>>>>> possible so that we can get watchdog protection for as much of the boot
>>>>> as we possibly can.
>>>>> So, if we are to block the SMC from Dom0, then Xen needs to take over
>>>>> the pinging. It could be implemented similarly to the NMI watchdog,
>>>>> except that the system will reset if the ping is missed rather than
>>>>> backtrace.
>>>>> It would also mean that Xen will get a whole watchdog driver-category
>>>>> due to the watchdog being vendor and sometimes even SoC specific when it
>>>>> comes to Arm.
>>>>> My understanding of the domain watchdog code is that today the domain
>>>>> needs to call SCHEDOP_watchdog at least once to start the watchdog
>>>>> timer. Since watchdog protection through the whole boot process is
>>>>> desirable we'd need some core changes, such as an option to start the
>>>>> domain watchdog on init. >
>>>>> It's quite a big change to make
>>>> 
>>>> For clarification, above you seem to mention two 

Re: [PATCH] docs/misra: add Rule 16.4

[Bertrand Marquis]

Hi Stefano,

> On 14 Mar 2024, at 00:04, Stefano Stabellini  wrote:
> 
> On Wed, 13 Mar 2024, Jan Beulich wrote:
>> On 13.03.2024 01:28, Stefano Stabellini wrote:
>>> --- a/docs/misra/rules.rst
>>> +++ b/docs/misra/rules.rst
>>> @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
>>>  - In addition to break, also other unconditional flow control 
>>> statements
>>>such as continue, return, goto are allowed.
>>> 
>>> +   * - `Rule 16.4 
>>> `_
>>> + - Required
>>> + - Every switch statement shall have a default label
>>> + - Switch statements with enums as controlling expression don't need
>>> +   a default label as gcc -Wall enables -Wswitch which warns (and
>>> +   breaks the build)
>> 
>> I think this could do with mentioning -Werror.
> 
> No problem
> 
> 
>>> if one of the enum labels is missing from the
>>> +   switch.
>>> +
>>> +   Switch statements with integer types as controlling expression
>>> +   should have a default label:
>>> +
>>> +   - if the switch is expected to handle all possible cases
>>> + explicitly, then a default label shall be added to handle
>>> + unexpected error conditions, using BUG(), ASSERT(), WARN(),
>>> + domain_crash(), or other appropriate methods;
>>> +
>>> +   - if the switch is expected to handle a subset of all
>>> + possible cases, then a default label shall be added with an
>>> + in-code comment as follows::
>>> +
>>> + /* only handle a subset of the possible cases */
>>> + default:
>>> + break;
>> 
>> Unless it being made crystal clear that mechanically reproducing this
>> comment isn't going to do, I'm going to have a hard time picking
>> between actively vetoing or just accepting if someone else acks this.
>> At the very least, though, the suggested (or, as requested, example)
>> comment should match ./CODING_STYLE. And it may need placing
>> differently if I understood correctly what Misra / Eclair demand
>> (between default: and break; rather than ahead of both).
>> 
>> The only place I'd accept a pre-cooked comment is to cover the
>> "notifier pattern".
> 
> Hi Jan, 
> 
> During the MISRA C call we discussed two distinct situations:
> 
> 1) when the default is not supposed to happen (it could be an BUG_ON)
> 2) when we only handle a subset of cases on purpose
> 
> For 2), it is useful to have a comment to clarify that we are dealing
> with 2) instead of 1). It is not a pre-cooked comment. The comment
> should be reviewed and checked that it is actually true that for this
> specific switch the default is expected and we should do nothing.
> 
> However, the comment is indeed pre-cooked in the sense that we don't
> need to have several different variations of them to explain why we only
> handle a subset of cases.
> 
> The majority of people on the call agreed with this (or so I understood).

In fact i do agree with Jan here somehow: we must not have a default comment
in the rules.rst.
It might be that a comment will look like that but I think it would be a 
mistake to
have a default one that people can just copy and paste without thinking.
I would suggest to put something like the following instead:
When a default is empty, a comment shall be added to state it with a reason
and when possible a more detailed explanation.

Regards
Bertrand

Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue

[Bertrand Marquis]

Hi,

> On 8 Mar 2024, at 15:04, Julien Grall  wrote:
> 
> Hi John,
> 
> Thank you for the reply.
> 
> On 08/03/2024 13:40, John Ernberg wrote:
>> On 3/7/24 00:07, Julien Grall wrote:
>>>  > Ping on the watchdog discussion bits.
>>> 
>>> Sorry for the late reply.
>>> 
>>> On 06/03/2024 13:13, John Ernberg wrote:
 On 2/9/24 14:14, John Ernberg wrote:
> 
>> * IMX_SIP_TIMER_*:  This seems to be related to the watchdog.
>> Shouldn't dom0 rely on the watchdog provided by Xen instead? So those
>> call will be used by Xen.
> 
> That is indeed a watchdog SIP, and also for setting the SoC internal RTC
> if it is being used.
> 
> I looked around if there was previous discussion and only really
> found [3].
> Is the xen/xen/include/watchdog.h header meant to be for this kind of
> watchdog support or is that more for the VM watchdog? Looking at the x86
> ACPI NMI watchdog it seems like the former, but I have never worked with
> x86 nor ACPI.
>>> 
>>> include/watchdog.h contains helper to configure the watchdog for Xen. We
>>> also have per-VM watchdog and this is configured by the hypercall
>>> SCHEDOP_watchdog.
>>> 
> 
> Currently forwarding it to Dom0 has not caused any watchdog resets with
> our watchdog timeout settings, our specific Dom0 setup and VM count.
>>> 
>>> IIUC, the SMC API for the watchdog would be similar to the ACPI NMI
>>> watchdog. So I think it would make more sense if this is not exposed to
>>> dom0 (even if Xen is doing nothing with it).
>>> 
>>> Can you try to hide the SMCs and check if dom0 still behave properly?
>>> 
>>> Cheers,
>>> 
>> This SMC manages a hardware watchdog, if it's not pinged within a
>> specific interval the entire board resets.
> 
> Do you know what's the default interval? Is it large enough so Xen + dom0 can 
> boot (at least up to when the watchdog driver is initialized)?
> 
>> If I block the SMCs the watchdog driver in Dom0 will fail to ping the
>> watchdog, triggering a board reset because the system looks to have
>> become unresponsive. The reason this patch set started is because we
>> couldn't ping the watchdog when running with Xen.
>> In our specific system the bootloader enables the watchdog as early as
>> possible so that we can get watchdog protection for as much of the boot
>> as we possibly can.
>> So, if we are to block the SMC from Dom0, then Xen needs to take over
>> the pinging. It could be implemented similarly to the NMI watchdog,
>> except that the system will reset if the ping is missed rather than
>> backtrace.
>> It would also mean that Xen will get a whole watchdog driver-category
>> due to the watchdog being vendor and sometimes even SoC specific when it
>> comes to Arm.
>> My understanding of the domain watchdog code is that today the domain
>> needs to call SCHEDOP_watchdog at least once to start the watchdog
>> timer. Since watchdog protection through the whole boot process is
>> desirable we'd need some core changes, such as an option to start the
>> domain watchdog on init. >
>> It's quite a big change to make
> 
> For clarification, above you seem to mention two changes:
> 
> 1) Allow Xen to use the HW watchdog
> 2) Allow the domain to use the watchdog early
> 
> I am assuming by big change, you are referring to 2?
> 
> , while I am not against doing it if it
>> makes sense, I now wonder if Xen should manage hardware watchdogs.
>> Looking at the domain watchdog code it looks like if a domain does not
>> get enough execution time, the watchdog will not be pinged enough and
>> the guest will be reset. So either watchdog approach requires Dom0 to
>> get execution time. Dom0 also needs to service all the PV backends it's
>> responsible for. I'm not sure it's valuable to add another layer of
>> watchdog for this scenario as the end result (checking that the entire
>> system works) is achieved without it as well.
>> So, before I try to find the time to make a proposal for moving the
>> hardware watchdog bit to Xen, do we really want it?
> 
> Thanks for the details. Given that the watchdog is enabled by the bootloader, 
> I think we want Xen to drive the watchdog for two reasons:
> 1) In true dom0less environment, dom0 would not exist
> 2) You are relying on Xen + Dom0 to boot (or at least enough to get the 
> watchdog working) within the watchdog interval.

Definitely we need to consider the case where there is no Dom0.

I think there are in fact 3 different use cases here:
- watchdog fully driven in a domain (dom0 or another): would work if it is 
expected
  that Xen + Domain boot time is under the watchdog initial refresh rate. I 
think this
  could make sense on some applications where your system depends on a specific
  domain to be properly booted to work. This would require an initial refresh 
time
  configurable in the boot loader probably.
- watchdog fully driven by Xen. One might want to just make sure the hypervisor 
is alive.
- hybrid model where the watchdog is 

Re: [PATCH v2 3/3] docs/misra/rules.rst: add rule 14.4

[Bertrand Marquis]

Hi Stefano,


> On 13 Feb 2024, at 23:33, Stefano Stabellini  
> wrote:
> 
> Signed-off-by: Stefano Stabellini 

Coherent with what was discussed during the Misra meeting so:

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> docs/misra/rules.rst | 9 +
> 1 file changed, 9 insertions(+)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index 931158b354..3e6f94d7bd 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -468,6 +468,15 @@ maintainers if you want to suggest a change.
> 
>while(0) and while(1) and alike are allowed.
> 
> +   * - `Rule 14.4 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_04.c>`_
> + - Required
> + - The controlling expression of an if-statement and the controlling
> +   expression of an iteration-statement shall have essentially
> +   Boolean type
> + - Automatic conversions of integer types to bool are permitted.
> +   Automatic conversions of pointer types to bool are permitted.
> +   This rule still applies to enum types.
> +
>* - `Rule 16.3 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_03.c>`_
>  - Required
>  - An unconditional break statement shall terminate every
> -- 
> 2.25.1
> 
> 

Re: [XEN PATCH v4] xen/arm: ffa: reclaim shared memory on guest destroy

[Bertrand Marquis]

Hi Jens,

> On 5 Feb 2024, at 16:49, Jens Wiklander  wrote:
> 
> When an FF-A enabled guest is destroyed it may leave behind memory
> shared with SPs. This memory must be reclaimed before it's reused or an
> SP may make changes to memory used by a new unrelated guest. So when the
> domain is teared down add FF-A requests to reclaim all remaining shared
> memory.
> 
> SPs in the secure world are notified using VM_DESTROYED that a guest has
> been destroyed. An SP is supposed to relinquish all shared memory to allow
> reclaiming the memory. The relinquish operation may need to be delayed if
> the shared memory is for instance part of a DMA operation.
> 
> The domain reference counter is increased when the first FF-A shared
> memory is registered and the counter is decreased again when the last
> shared memory is reclaimed. If FF-A shared memory registrations remain
> at the end of of ffa_domain_teardown() a timer is set to try to reclaim
> the shared memory every second until the memory is reclaimed.
> 
> A few minor style fixes with a removed empty line here and an added new
> line there.
> 
> Signed-off-by: Jens Wiklander 

>From my point of view all looks good now so with the changes requested
by Andrew handled, feel free to add my R-b in the v5:

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> 
> v4:
> - Retry FFA_MSG_SEND_VM_DESTROYED on the returned errors
>  FFA_RET_INTERRUPTED and FFA_RET_RETRY even after all shared memory
>  handles has been reclaimed.
> - Retry ffa_mem_reclaim() only on temporary returned errors, permanent
>  errors like FFA_RET_INVALID_PARAMETERS is dealt with in recovery mode
>  instead since the SPMC isn't expected to use that error under normal
>  circumstances.
> 
> v3:
> - Mentioning in the commit message that there are some style fixes
> - Addressing review comments
> - Refactor the ffa_domain_teardown() path to let
>  ffa_domain_teardown_continue() do most of the work.
> 
> v2:
> - Update commit message to match the new implementation
> - Using a per domain bitfield to keep track of which SPs has been notified
>  with VM_DESTROYED
> - Holding a domain reference counter to keep the domain as a zombie domain
>  while there still is shared memory registrations remaining to be reclaimed
> - Using a timer to retry reclaiming remaining shared memory registrations
> ---
> xen/arch/arm/tee/ffa.c | 285 ++---
> 1 file changed, 236 insertions(+), 49 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 0793c1c7585d..bbb6b819ee2b 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -54,6 +54,7 @@
> #include 
> #include 
> #include 
> +#include 
> #include 
> 
> #include 
> @@ -144,6 +145,12 @@
>  */
> #define FFA_MAX_SHM_COUNT   32
> 
> +/*
> + * The time we wait until trying to tear down a domain again if it was
> + * blocked initially.
> + */
> +#define FFA_CTX_TEARDOWN_DELAY  SECONDS(1)
> +
> /* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
> #define FFA_HANDLE_HYP_FLAG BIT(63, ULL)
> #define FFA_HANDLE_INVALID  0xULL
> @@ -384,11 +391,6 @@ struct ffa_ctx {
> unsigned int page_count;
> /* FF-A version used by the guest */
> uint32_t guest_vers;
> -/*
> - * Number of SPs that we have sent a VM created signal to, used in
> - * ffa_domain_teardown() to know which SPs need to be signalled.
> - */
> -uint16_t create_signal_count;
> bool rx_is_free;
> /* Used shared memory objects, struct ffa_shm_mem */
> struct list_head shm_list;
> @@ -402,6 +404,15 @@ struct ffa_ctx {
> spinlock_t tx_lock;
> spinlock_t rx_lock;
> spinlock_t lock;
> +/* Used if domain can't be torn down immediately */
> +struct domain *teardown_d;
> +struct list_head teardown_list;
> +s_time_t teardown_expire;
> +/*
> + * Used for ffa_domain_teardown() to keep track of which SPs should be
> + * notified that this guest is being destroyed.
> + */
> +unsigned long vm_destroy_bitmap[];
> };
> 
> struct ffa_shm_mem {
> @@ -436,6 +447,12 @@ static void *ffa_tx __read_mostly;
> static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> static DEFINE_SPINLOCK(ffa_tx_buffer_lock);
> 
> +
> +/* Used to track domains that could not be torn down immediately. */
> +static struct timer ffa_teardown_timer;
> +static struct list_head ffa_teardown_head;
> +static DEFINE_SPINLOCK(ffa_teardown_lock);
> +
> static bool ffa_get_version(uint32_t *vers)
> {
> const struct arm_smccc_1_2_regs arg = {
> @@ -853,7 +870,6 @@ static int32

Re: [PATCH] xen: Swap order of actions in the FREE*() macros

[Bertrand Marquis]

Hi Andrew,


> On 2 Feb 2024, at 00:39, Andrew Cooper  wrote:
> 
> Wherever possible, it is a good idea to NULL out the visible reference to an
> object prior to freeing it.  The FREE*() macros already collect together both
> parts, making it easy to adjust.
> 
> This has a marginal code generation improvement, as some of the calls to the
> free() function can be tailcall optimised.
> 

Could you improve a bit the commit message and explain a bit why it is a good 
idea
and also how the code might be improved because i do not get it ?

Cheers
Bertrand

> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: George Dunlap 
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> CC: Julien Grall 
> ---
> xen/include/xen/mm.h  | 3 ++-
> xen/include/xen/xmalloc.h | 7 ---
> 2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index 3d9b2d05a5c8..044f3f3b19c8 100644
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -92,8 +92,9 @@ bool scrub_free_pages(void);
> 
> /* Free an allocation, and zero the pointer to it. */
> #define FREE_XENHEAP_PAGES(p, o) do { \
> -free_xenheap_pages(p, o); \
> +void *_ptr_ = (p);\
> (p) = NULL;   \
> +free_xenheap_pages(_ptr_, o); \
> } while ( false )
> #define FREE_XENHEAP_PAGE(p) FREE_XENHEAP_PAGES(p, 0)
> 
> diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
> index 9ecddbff5e00..1b88a83be879 100644
> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -66,9 +66,10 @@
> extern void xfree(void *p);
> 
> /* Free an allocation, and zero the pointer to it. */
> -#define XFREE(p) do { \
> -xfree(p); \
> -(p) = NULL;   \
> +#define XFREE(p) do {   \
> +void *_ptr_ = (p);  \
> +(p) = NULL; \
> +xfree(_ptr_);   \
> } while ( false )
> 
> /* Underlying functions */
> 
> base-commit: 3f819af8a796c0e2f798dd301ec8c3f8cccbc9fc
> -- 
> 2.30.2
> 
> 

Re: [XEN PATCH v3] xen/arm: ffa: reclaim shared memory on guest destroy

[Bertrand Marquis]

Hi Jens,

> On 5 Feb 2024, at 14:39, Jens Wiklander  wrote:
> 
> Hi Bertrand,
> 
> On Thu, Feb 1, 2024 at 2:57 PM Bertrand Marquis
>  wrote:
>> 
>> Hi Jens,
>> 
>>> On 17 Jan 2024, at 12:06, Jens Wiklander  wrote:
>>> 
>>> When an FF-A enabled guest is destroyed it may leave behind memory
>>> shared with SPs. This memory must be reclaimed before it's reused or an
>>> SP may make changes to memory used by a new unrelated guest. So when the
>>> domain is teared down add FF-A requests to reclaim all remaining shared
>>> memory.
>>> 
>>> SPs in the secure world are notified using VM_DESTROYED that a guest has
>>> been destroyed. An SP is supposed to relinquish all shared memory to allow
>>> reclaiming the memory. The relinquish operation may need to be delayed if
>>> the shared memory is for instance part of a DMA operation.
>>> 
>>> The domain reference counter is increased when the first FF-A shared
>>> memory is registered and the counter is decreased again when the last
>>> shared memory is reclaimed. If FF-A shared memory registrations remain
>>> at the end of of ffa_domain_teardown() a timer is set to try to reclaim
>>> the shared memory every second until the memory is reclaimed.
>>> 
>>> A few minor style fixes with a removed empty line here and an added new
>>> line there.
>>> 
>>> Signed-off-by: Jens Wiklander 
>>> ---
>>> 
>>> v3:
>>> - Mentioning in the commit message that there are some style fixes
>>> - Addressing review comments
>>> - Refactor the ffa_domain_teardown() path to let
>>> ffa_domain_teardown_continue() do most of the work.
>>> 
>>> v2:
>>> - Update commit message to match the new implementation
>>> - Using a per domain bitfield to keep track of which SPs has been notified
>>> with VM_DESTROYED
>>> - Holding a domain reference counter to keep the domain as a zombie domain
>>> while there still is shared memory registrations remaining to be reclaimed
>>> - Using a timer to retry reclaiming remaining shared memory registrations
>>> ---
>>> xen/arch/arm/tee/ffa.c | 253 +
>>> 1 file changed, 204 insertions(+), 49 deletions(-)
>>> 
>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>>> index 0793c1c7585d..80ebbf4f01c6 100644
>>> --- a/xen/arch/arm/tee/ffa.c
>>> +++ b/xen/arch/arm/tee/ffa.c
>>> @@ -54,6 +54,7 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> 
>>> #include 
>>> @@ -144,6 +145,12 @@
>>> */
>>> #define FFA_MAX_SHM_COUNT   32
>>> 
>>> +/*
>>> + * The time we wait until trying to tear down a domain again if it was
>>> + * blocked initially.
>>> + */
>>> +#define FFA_CTX_TEARDOWN_DELAY  SECONDS(1)
>>> +
>>> /* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
>>> #define FFA_HANDLE_HYP_FLAG BIT(63, ULL)
>>> #define FFA_HANDLE_INVALID  0xULL
>>> @@ -384,11 +391,6 @@ struct ffa_ctx {
>>>unsigned int page_count;
>>>/* FF-A version used by the guest */
>>>uint32_t guest_vers;
>>> -/*
>>> - * Number of SPs that we have sent a VM created signal to, used in
>>> - * ffa_domain_teardown() to know which SPs need to be signalled.
>>> - */
>>> -uint16_t create_signal_count;
>>>bool rx_is_free;
>>>/* Used shared memory objects, struct ffa_shm_mem */
>>>struct list_head shm_list;
>>> @@ -402,6 +404,15 @@ struct ffa_ctx {
>>>spinlock_t tx_lock;
>>>spinlock_t rx_lock;
>>>spinlock_t lock;
>>> +/* Used if domain can't be torn down immediately */
>>> +struct domain *teardown_d;
>>> +struct list_head teardown_list;
>>> +s_time_t teardown_expire;
>>> +/*
>>> + * Used for ffa_domain_teardown() to keep track of which SPs should be
>>> + * notified that this guest is being destroyed.
>>> + */
>>> +unsigned long vm_destroy_bitmap[];
>>> };
>>> 
>>> struct ffa_shm_mem {
>>> @@ -436,6 +447,12 @@ static void *ffa_tx __read_mostly;
>>> static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
>>> static DEFINE_SPINLOCK(ffa_tx_buffer_lock);
>>> 
>>> +
>&

Re: [XEN PATCH v3] xen/arm: ffa: reclaim shared memory on guest destroy

[Bertrand Marquis]

Hi Jens,

> On 17 Jan 2024, at 12:06, Jens Wiklander  wrote:
> 
> When an FF-A enabled guest is destroyed it may leave behind memory
> shared with SPs. This memory must be reclaimed before it's reused or an
> SP may make changes to memory used by a new unrelated guest. So when the
> domain is teared down add FF-A requests to reclaim all remaining shared
> memory.
> 
> SPs in the secure world are notified using VM_DESTROYED that a guest has
> been destroyed. An SP is supposed to relinquish all shared memory to allow
> reclaiming the memory. The relinquish operation may need to be delayed if
> the shared memory is for instance part of a DMA operation.
> 
> The domain reference counter is increased when the first FF-A shared
> memory is registered and the counter is decreased again when the last
> shared memory is reclaimed. If FF-A shared memory registrations remain
> at the end of of ffa_domain_teardown() a timer is set to try to reclaim
> the shared memory every second until the memory is reclaimed.
> 
> A few minor style fixes with a removed empty line here and an added new
> line there.
> 
> Signed-off-by: Jens Wiklander 
> ---
> 
> v3:
> - Mentioning in the commit message that there are some style fixes
> - Addressing review comments
> - Refactor the ffa_domain_teardown() path to let
>  ffa_domain_teardown_continue() do most of the work.
> 
> v2:
> - Update commit message to match the new implementation
> - Using a per domain bitfield to keep track of which SPs has been notified
>  with VM_DESTROYED
> - Holding a domain reference counter to keep the domain as a zombie domain
>  while there still is shared memory registrations remaining to be reclaimed
> - Using a timer to retry reclaiming remaining shared memory registrations
> ---
> xen/arch/arm/tee/ffa.c | 253 +
> 1 file changed, 204 insertions(+), 49 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 0793c1c7585d..80ebbf4f01c6 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -54,6 +54,7 @@
> #include 
> #include 
> #include 
> +#include 
> #include 
> 
> #include 
> @@ -144,6 +145,12 @@
>  */
> #define FFA_MAX_SHM_COUNT   32
> 
> +/*
> + * The time we wait until trying to tear down a domain again if it was
> + * blocked initially.
> + */
> +#define FFA_CTX_TEARDOWN_DELAY  SECONDS(1)
> +
> /* FF-A-1.1-REL0 section 10.9.2 Memory region handle, page 167 */
> #define FFA_HANDLE_HYP_FLAG BIT(63, ULL)
> #define FFA_HANDLE_INVALID  0xULL
> @@ -384,11 +391,6 @@ struct ffa_ctx {
> unsigned int page_count;
> /* FF-A version used by the guest */
> uint32_t guest_vers;
> -/*
> - * Number of SPs that we have sent a VM created signal to, used in
> - * ffa_domain_teardown() to know which SPs need to be signalled.
> - */
> -uint16_t create_signal_count;
> bool rx_is_free;
> /* Used shared memory objects, struct ffa_shm_mem */
> struct list_head shm_list;
> @@ -402,6 +404,15 @@ struct ffa_ctx {
> spinlock_t tx_lock;
> spinlock_t rx_lock;
> spinlock_t lock;
> +/* Used if domain can't be torn down immediately */
> +struct domain *teardown_d;
> +struct list_head teardown_list;
> +s_time_t teardown_expire;
> +/*
> + * Used for ffa_domain_teardown() to keep track of which SPs should be
> + * notified that this guest is being destroyed.
> + */
> +unsigned long vm_destroy_bitmap[];
> };
> 
> struct ffa_shm_mem {
> @@ -436,6 +447,12 @@ static void *ffa_tx __read_mostly;
> static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> static DEFINE_SPINLOCK(ffa_tx_buffer_lock);
> 
> +
> +/* Used to track domains that could not be torn down immediately. */
> +static struct timer ffa_teardown_timer;
> +static struct list_head ffa_teardown_head;
> +static DEFINE_SPINLOCK(ffa_teardown_lock);
> +
> static bool ffa_get_version(uint32_t *vers)
> {
> const struct arm_smccc_1_2_regs arg = {
> @@ -853,7 +870,6 @@ static int32_t handle_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> goto out_rx_release;
> }
> 
> -
> memcpy(ctx->rx, ffa_rx, sz);
> }
> ctx->rx_is_free = false;
> @@ -992,53 +1008,75 @@ static void put_shm_pages(struct ffa_shm_mem *shm)
> }
> }
> 
> -static bool inc_ctx_shm_count(struct ffa_ctx *ctx)
> +static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
> {
> bool ret = true;
> 
> spin_lock(>lock);
> +
> +/*
> + * If this is the first shm added, increase the domain reference
> + * counter as we need to keep domain around a bit longer to reclaim the
> + * shared memory in the teardown path.
> + */
> +if ( !ctx->shm_count )
> +get_knownalive_domain(d);
> +
> if (ctx->shm_count >= FFA_MAX_SHM_COUNT)
> ret = false;
> else
> ctx->shm_count++;
> +
> spin_unlock(>lock);
> 
> return ret;
> }
> 
> 

Re: [PATCH] xen/arm: Properly clean update to init_ttbr and smp_up_cpu

[Bertrand Marquis]

Hi Julien,

Nice finding :-)

> On 30 Jan 2024, at 18:29, Julien Grall  wrote:
> 
> From: Julien Grall 
> 
> Recent rework to the secondary boot code modified how init_ttbr and
> smp_up_cpu are accessed. Rather than directly accessing them, we
> are using a pointer to them.
> 
> The helper clean_dcache() is expected to take the variable in parameter
> and then clean its content. As we now pass a pointer to the variable,
> we will clean the area storing the address rather than the content itself.
> 
> Switch to use clean_dcache_va_range() to avoid casting the pointer.
> 
> Fixes: a5ed59e62c6f ("arm/mmu: Move init_ttbr to a new section .data.idmap")
> Fixes: 9a5114074b04 ("arm/smpboot: Move smp_up_cpu to a new section 
> .data.idmap)
> 
> Reported-by: Oleksandr Tyshchenko 
> Signed-off-by: Julien Grall 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/mmu/smpboot.c | 2 +-
> xen/arch/arm/smpboot.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/mmu/smpboot.c b/xen/arch/arm/mmu/smpboot.c
> index bc91fdfe3331..4ffc8254a44b 100644
> --- a/xen/arch/arm/mmu/smpboot.c
> +++ b/xen/arch/arm/mmu/smpboot.c
> @@ -88,7 +88,7 @@ static void set_init_ttbr(lpae_t *root)
>  * init_ttbr will be accessed with the MMU off, so ensure the update
>  * is visible by cleaning the cache.
>  */
> -clean_dcache(ptr);
> +clean_dcache_va_range(ptr, sizeof(uint64_t));
> 
> unmap_domain_page(ptr);
> }
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index 119bfa3160ad..a84e706d77da 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -449,7 +449,7 @@ static void set_smp_up_cpu(unsigned long mpidr)
>  * smp_up_cpu will be accessed with the MMU off, so ensure the update
>  * is visible by cleaning the cache.
>  */
> -clean_dcache(ptr);
> +clean_dcache_va_range(ptr, sizeof(unsigned long));
> 
> unmap_domain_page(ptr);
> 
> -- 
> 2.40.1
> 

Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs

[Bertrand Marquis]

Hi Andrew,

> On 25 Jan 2024, at 00:27, Andrew Cooper  wrote:
> 
> On 23/01/2024 8:29 am, Bertrand Marquis wrote:
>>> Thanks for raising the visibility of this.  I'm not familiar with ARM,
>>> but if I were investigating this I'd try to figure out what the
>>> "unhandled" error messages are.  "gnttab_mark_dirty not implemented
>>> yet" looks pretty sus too, and also sounds like it might be something
>>> ARM-specific.
>> I tried to explain those and they are not the reason of the problem.
> 
> The "gnttab_mark_dirty not implemented yet" printk() should be deleted.
> 
> It's /* TODO - logdirty support */ in a form that is actively unhelpful
> to people using a debug hypervisor to debug other things.

Could make sense.
It is true that this one appears in all debug log but it might not be
very useful in fact.

@julien and Stefano: what would you say ?

Bertrand

> 
> ~Andrew

Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs

[Bertrand Marquis]

Hi Paul,

Please keep me in CC so that i can more easily find out that you answered me :-)

> On 25 Jan 2024, at 00:05, Paul Leiber  wrote:
> 
> Elliot, Bertrand, George: Thanks for your replies.
> 
> Am 23.01.2024 um 09:29 schrieb Bertrand Marquis:
>> Hi,
>>  will try to explain some of the messages here after but I am not sure of 
>> the reason
>> of the crash so I will just set some pointers...
>>> On 22 Jan 2024, at 11:46, George Dunlap  wrote:
>>> 
>>> On Fri, Jan 19, 2024 at 8:32 PM Elliott Mitchell  wrote:
>>>> 
>>>> On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote:
>>>>> 
>>>>> Am 22.10.2023 um 07:42 schrieb Paul Leiber:
>>>>>> Am 13.10.2023 um 20:56 schrieb Paul Leiber:
>>>>>>> Hi Xen developers list,
>>>>>>> 
>>>>>>> TL;DR:
>>>>>>> --
>>>>>>> 
>>>>>>> Causing certain web server traffic on a secondary VLAN on Raspberry Pi
>>>>>>> under vanilla Debian/UEFI in combination with Xen leads to complete
>>>>>>> system reboot (watchdog triggering for Dom0). Other strange things are
>>>>>>> happening.
>>>>>>> 
>>>>>>> Description:
>>>>>>> --
>>>>>>> 
>>>>>>> I recently set up Xen (self compiled, Version 4.18-rc) on a Raspberry
>>>>>>> Pi 4B (on vanilla Debian Bookworm, UEFI boot mode). Until some time
>>>>>>> ago, everything worked well with Dom0, one DomU and one bridge.
>>>>>>> 
>>>>>>> Then I wanted to actually make use of the virtualization and started
>>>>>>> to set up a second Debian Bookworm DomU (using xen-create-image) for
>>>>>>> monitoring my systems with zabbix (a webserver based system monitoring
>>>>>>> solution). The bridge used for this setup was the device bridging the
>>>>>>> hardware NIC. I installed zabbix, set it up, and everything went well,
>>>>>>> I could access the web interface without any problem.
>>>>>>> 
>>>>>>> Then I set up VLANs (initally using VLAN numbers 1 and 2) to separate
>>>>>>> network traffic between the DomUs. I made the existing device bridge
>>>>>>> VLAN 1 (bridge 1) and created a secondary device for bridging VLAN 2
>>>>>>> (bridge 2). Using only bridge 1 / VLAN 1 everything works well, I can
>>>>>>> access the zabbix web interface without any noticeable issue. After
>>>>>>> switching the zabbix DomU to VLAN 2 / bridge 2, everything seemingly
>>>>>>> keeps on working well, I can ping different devices in my network from
>>>>>>> the zabbix DomU and vice versa, I can ssh into the machine.
>>>>>>> 
>>>>>>> However, as soon as I remotely access the zabbix web interface, the
>>>>>>> complete system (DomUs and Dom0) becomes unresponsive and reboots
>>>>>>> after some time (usually seconds, sometimes 1-2 minutes). The reboot
>>>>>>> is reliably reproducable.
>>>>>>> 
>>>>>>> I didn't see any error message in any log (zabbix, DomU syslog, Dom0
>>>>>>> syslog) except for the following lines immediately before the system
>>>>>>> reboots on the Xen serial console:
>>>>>>> 
>>>>>>> (XEN) Watchdog timer fired for domain 0
>>>>>>> (XEN) Hardware Dom0 shutdown: watchdog rebooting machine
>>>>>>> 
>>>>>>> As soon as I change the bridge to bridge 1 (with or without VLAN
>>>>>>> setup), the web interface is accessible again after booting the zabbix
>>>>>>> DomU, no reboots.
>>>>>>> 
>>>>>>> So I assume that causing specific traffic on the virtual NIC when
>>>>>>> using a VLAN setup with more than one VLAN under Xen makes the Dom0
>>>>>>> system hard crash. Of course, there might be other causes that I'm not
>>>>>>> aware of, but to me, this seems to be the most likely explanation
>>>>>>> right now.
>>>>>>> 
>>>>>>> What I tried:
>>>>>>> -
>>>>>>> 
>>>>>>> 1. I changed the VLAN numbers. First 

Re: Xen 4.18rc/ARM64 on Raspberry Pi 4B: Traffic in DomU crashing Dom0 when using VLANs

[Bertrand Marquis]

Hi,

 will try to explain some of the messages here after but I am not sure of the 
reason
of the crash so I will just set some pointers...

> On 22 Jan 2024, at 11:46, George Dunlap  wrote:
> 
> On Fri, Jan 19, 2024 at 8:32 PM Elliott Mitchell  wrote:
>> 
>> On Sun, Jan 14, 2024 at 10:54:24PM +0100, Paul Leiber wrote:
>>> 
>>> Am 22.10.2023 um 07:42 schrieb Paul Leiber:
 Am 13.10.2023 um 20:56 schrieb Paul Leiber:
> Hi Xen developers list,
> 
> TL;DR:
> --
> 
> Causing certain web server traffic on a secondary VLAN on Raspberry Pi
> under vanilla Debian/UEFI in combination with Xen leads to complete
> system reboot (watchdog triggering for Dom0). Other strange things are
> happening.
> 
> Description:
> --
> 
> I recently set up Xen (self compiled, Version 4.18-rc) on a Raspberry
> Pi 4B (on vanilla Debian Bookworm, UEFI boot mode). Until some time
> ago, everything worked well with Dom0, one DomU and one bridge.
> 
> Then I wanted to actually make use of the virtualization and started
> to set up a second Debian Bookworm DomU (using xen-create-image) for
> monitoring my systems with zabbix (a webserver based system monitoring
> solution). The bridge used for this setup was the device bridging the
> hardware NIC. I installed zabbix, set it up, and everything went well,
> I could access the web interface without any problem.
> 
> Then I set up VLANs (initally using VLAN numbers 1 and 2) to separate
> network traffic between the DomUs. I made the existing device bridge
> VLAN 1 (bridge 1) and created a secondary device for bridging VLAN 2
> (bridge 2). Using only bridge 1 / VLAN 1 everything works well, I can
> access the zabbix web interface without any noticeable issue. After
> switching the zabbix DomU to VLAN 2 / bridge 2, everything seemingly
> keeps on working well, I can ping different devices in my network from
> the zabbix DomU and vice versa, I can ssh into the machine.
> 
> However, as soon as I remotely access the zabbix web interface, the
> complete system (DomUs and Dom0) becomes unresponsive and reboots
> after some time (usually seconds, sometimes 1-2 minutes). The reboot
> is reliably reproducable.
> 
> I didn't see any error message in any log (zabbix, DomU syslog, Dom0
> syslog) except for the following lines immediately before the system
> reboots on the Xen serial console:
> 
> (XEN) Watchdog timer fired for domain 0
> (XEN) Hardware Dom0 shutdown: watchdog rebooting machine
> 
> As soon as I change the bridge to bridge 1 (with or without VLAN
> setup), the web interface is accessible again after booting the zabbix
> DomU, no reboots.
> 
> So I assume that causing specific traffic on the virtual NIC when
> using a VLAN setup with more than one VLAN under Xen makes the Dom0
> system hard crash. Of course, there might be other causes that I'm not
> aware of, but to me, this seems to be the most likely explanation
> right now.
> 
> What I tried:
> -
> 
> 1. I changed the VLAN numbers. First to 101, 102, 103 etc. This was
> when I noticed another strange thing: VLANs with numbers >99 simply
> don't work on my Raspberry Pi under Debian, with or without Xen. VLAN
> 99 works, VLAN 100 (or everything else >99 that I tried) doesn't work.
> If I choose a number >99, the VLAN is not configured, "ip a" doesn't
> list it. Other Debian systems on x64 architecture don't show this
> behavior, there, it was no problem to set up VLANs > 99. Therefore,
> I've changed the VLANs to 10, 20, 30 etc., which worked. But it didn't
> solve the initial problem of the crashing Dom0 and DomUs.
> 
> 2. Different bridge options, without noticable effect:
> bridge_stp off  # dont use STP (spanning tree proto)
> bridge_waitport 0   # dont wait for port to be available
> bridge_fd 0 # no forward delay
> 
> 3. Removing IPv6: No noticable effect.
> 
> 4. Network traffic analysis: Now, here it becomes _really_ strange. I
> started tcpdumps on Dom0, and depending on on which interface/bridge
> traffic was logged, the problem went away, meaning, the DomU was
> running smoothly for hours, even when accessing the zabbix web
> interface. Stopping the log makes the system crash (as above, after
> seconds up to 1-2 minutes) reproducably if I access the zabbix web
> interface.
> 
> Logging enabcm6e4ei0 (NIC): no crashes
> Logging enabcm6e4ei0.10 (VLAN 10): instant crash
> Logging enabcm6e4ei0.20 (VLAN 20): no crashes
> Logging xenbr0 (on VLAN 10): instant crash
> Logging xenbr1 (on VLAN 20): no crashes
> 
> I am clinging to the thought that there must be a rational explanation
> for why logging the traffic on certain 

Re: [XEN PATCH v2] xen/arm: ffa: reclaim shared memory on guest destroy

[Bertrand Marquis]

Hi Jens,

Very sorry for the long delay.

> On 13 Dec 2023, at 12:25, Jens Wiklander  wrote:
> 
> When an FF-A enabled guest is destroyed it may leave behind memory
> shared with SPs. This memory must be reclaimed before it's reused or an
> SP may make changes to memory used by a new unrelated guest. So when the
> domain is teared down add FF-A requests to reclaim all remaining shared
> memory.
> 
> SPs in the secure world are notified using VM_DESTROYED that a guest has
> been destroyed. An SP is supposed to relinquish all shared memory to allow
> reclaiming the memory. The relinquish operation may need to be delayed if
> the shared memory is for instance part of a DMA operation.
> 
> The domain reference counter is increased when the first FF-A shared
> memory is registered and the counter is decreased again when the last
> shared memory is reclaimed. If FF-A shared memory registrations remain
> at the end of of ffa_domain_teardown() a timer is set to try to reclaim
> the shared memory every second until the memory is reclaimed.
> 
> Signed-off-by: Jens Wiklander 
> ---
> Hi,
> 
> This is a follow-up to the RFC patch. In this patch, I take an explicit
> reference on the domain when FF-A shared memory is registered. I've
> discovered that it might not be strictly necessary until all the shared
> pages are released with put_page() they also keep a reference to the
> domain.
> 
> I'm not entirely sure what is the status of the shared memory when the
> domain has turned into a zombie. We still hold references on the shared
> pages until put_page() is called on each. Is that enough to guarantee that
> they will not be reused?
> 
> Thanks,
> Jens
> 
> v2:
> - Update commit message to match the new implementation
> - Using a per domain bitfield to keep track of which SPs has been notified
>  with VM_DESTROYED
> - Holding a domain reference counter to keep the domain as a zombie domain
>  while there still is shared memory registrations remaining to be reclaimed
> - Using a timer to retry reclaiming remaining shared memory registrations
> 
> ---
> xen/arch/arm/tee/ffa.c | 270 ++---
> 1 file changed, 224 insertions(+), 46 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 183528d13388..22906a6e1cff 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -54,6 +54,7 @@
> #include 
> #include 
> #include 
> +#include 
> #include 
> 
> #include 
> @@ -384,11 +385,6 @@ struct ffa_ctx {
> unsigned int page_count;
> /* FF-A version used by the guest */
> uint32_t guest_vers;
> -/*
> - * Number of SPs that we have sent a VM created signal to, used in
> - * ffa_domain_teardown() to know which SPs need to be signalled.
> - */
> -uint16_t create_signal_count;
> bool rx_is_free;
> /* Used shared memory objects, struct ffa_shm_mem */
> struct list_head shm_list;
> @@ -402,6 +398,15 @@ struct ffa_ctx {
> spinlock_t tx_lock;
> spinlock_t rx_lock;
> spinlock_t lock;
> +/* Used if domain can't be teared down immediately */
> +struct domain *teardown_d;
> +struct list_head teardown_list;
> +s_time_t teardown_expire;
> +/*
> + * Used for ffa_domain_teardown() to keep track of which SPs should be
> + * notified that this guest is being destroyed.
> + */
> +unsigned long vm_destroy_bitmap[];
> };
> 
> struct ffa_shm_mem {
> @@ -436,6 +441,12 @@ static void *ffa_tx __read_mostly;
> static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> static DEFINE_SPINLOCK(ffa_tx_buffer_lock);
> 
> +
> +/* Used if domain can't be teared down immediately */

Please adapt the comment as this for all domains.
Suggest: Used to track domains that could not be teared down immediately.

> +static struct timer ffa_teardown_timer;
> +static struct list_head ffa_teardown_head;
> +static DEFINE_SPINLOCK(ffa_teardown_lock);
> +
> static bool ffa_get_version(uint32_t *vers)
> {
> const struct arm_smccc_1_2_regs arg = {
> @@ -850,7 +861,6 @@ static int32_t handle_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> goto out_rx_release;
> }
> 
> -

You have several style changes like that in the patch.
Those are not major so I am ok if you keep them in the patch but please
mention in the commit messages that you do some code style fixes.

> memcpy(ctx->rx, ffa_rx, sz);
> }
> ctx->rx_is_free = false;
> @@ -989,53 +999,75 @@ static void put_shm_pages(struct ffa_shm_mem *shm)
> }
> }
> 
> -static bool inc_ctx_shm_count(struct ffa_ctx *ctx)
> +static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx)
> {
> bool ret = true;
> 
> spin_lock(>lock);
> +
> +/*
> + * If this is the first shm added, increase the domain reference
> + * counter as we may need to domain around a bit longer to reclaim the

This sentence needs fixing (need to keep the domain..)

> + * shared memory in the teardown path.
> + */
> +

Re: [XEN PATCH 7/7] xen/arm: smmu-v3: address violations of MISRA C:2012 Rule 16.3

[Bertrand Marquis]

Hi Frederico,

Sorry to have missed that one.

> On 20 Dec 2023, at 12:03, Federico Serafini  
> wrote:
> 
> Add a break statement at the end of the switch-clauses to address
> violations of MISRA C:2012 Rule 16.3 ("An unconditional `break'
> statement shall terminate every switch-clause").
> No funtional change.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Bertrand Marquis  ---
> xen/drivers/passthrough/arm/smmu-v3.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
> b/xen/drivers/passthrough/arm/smmu-v3.c
> index cdbb505134..bca5866b35 100644
> --- a/xen/drivers/passthrough/arm/smmu-v3.c
> +++ b/xen/drivers/passthrough/arm/smmu-v3.c
> @@ -2200,6 +2200,7 @@ static int arm_smmu_device_hw_probe(struct 
> arm_smmu_device *smmu)
> fallthrough;
> case IDR0_STALL_MODEL_STALL:
> smmu->features |= ARM_SMMU_FEAT_STALLS;
> + break;
> }
> 
> if (reg & IDR0_S2P)
> @@ -2301,6 +2302,7 @@ static int arm_smmu_device_hw_probe(struct 
> arm_smmu_device *smmu)
> fallthrough;
> case IDR5_OAS_48_BIT:
> smmu->oas = 48;
> + break;
> }
> 
> smmu->oas = min_t(unsigned long, PADDR_BITS, smmu->oas);
> -- 
> 2.34.1
> 

Re: [XEN PATCH] xen/arm: ffa: return fpi size from FFA_PARTITION_INFO_GET

[Bertrand Marquis]

Hi Jens,

> On 13 Dec 2023, at 11:31, Jens Wiklander  wrote:
> 
> Until now has FFA_PARTITION_INFO_GET always returned zero in w3, but
> FF-A v1.1 requires FFA_PARTITION_INFO_GET to return the size of each
> partition information descriptor returned if
> FFA_PARTITION_INFO_GET_COUNT_FLAG isn't set.
> 

Good finding.

> The SPMC queried with FFA_PARTITION_INFO_GET must also return the each
> partition information descriptor returned so fix this by passing along
> the same value.
> 
> Fixes: caf6491e95a9 ("xen/arm: ffa: support guest FFA_PARTITION_INFO_GET")
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 183528d13388..1d4e0a083006 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -514,7 +514,7 @@ static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t 
> rx_addr,
> 
> static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
>   uint32_t w4, uint32_t w5,
> -  uint32_t *count)
> +  uint32_t *count, uint32_t *fpi_size)
> {
> const struct arm_smccc_1_2_regs arg = {
> .a0 = FFA_PARTITION_INFO_GET,
> @@ -531,7 +531,10 @@ static int32_t ffa_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> 
> ret = get_ffa_ret_code();
> if ( !ret )
> +{
> *count = resp.a2;
> +*fpi_size = resp.a3;
> +}
> 
> return ret;
> }
> @@ -784,7 +787,7 @@ static uint32_t handle_rxtx_unmap(void)
> 
> static int32_t handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t 
> w3,
>  uint32_t w4, uint32_t w5,
> - uint32_t *count)
> + uint32_t *count, uint32_t *fpi_size)
> {
> int32_t ret = FFA_RET_DENIED;
> struct domain *d = current->domain;
> @@ -799,7 +802,7 @@ static int32_t handle_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
>  */
> if ( w5 == FFA_PARTITION_INFO_GET_COUNT_FLAG &&
>  ctx->guest_vers == FFA_VERSION_1_1 )
> -return ffa_partition_info_get(w1, w2, w3, w4, w5, count);
> +return ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
> if ( w5 )
> return FFA_RET_INVALID_PARAMETERS;
> 
> @@ -812,7 +815,7 @@ static int32_t handle_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> if ( !ctx->page_count || !ctx->rx_is_free )
> goto out;
> spin_lock(_rx_buffer_lock);
> -ret = ffa_partition_info_get(w1, w2, w3, w4, w5, count);
> +ret = ffa_partition_info_get(w1, w2, w3, w4, w5, count, fpi_size);
> if ( ret )
> goto out_rx_buf_unlock;
> /*
> @@ -842,7 +845,7 @@ static int32_t handle_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> }
> else
> {
> -size_t sz = *count * sizeof(struct ffa_partition_info_1_1);
> +size_t sz = *count * *fpi_size;
> 
> if ( ctx->page_count * FFA_PAGE_SIZE < sz )
> {
> @@ -1409,6 +1412,7 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> uint32_t fid = get_user_reg(regs, 0);
> struct domain *d = current->domain;
> struct ffa_ctx *ctx = d->arch.tee;
> +uint32_t fpi_size;
> uint32_t count;
> int e;
> 
> @@ -1444,11 +1448,11 @@ static bool ffa_handle_call(struct cpu_user_regs 
> *regs)
>   get_user_reg(regs, 2),
>   get_user_reg(regs, 3),
>   get_user_reg(regs, 4),
> -  get_user_reg(regs, 5), );
> +  get_user_reg(regs, 5), , 
> _size);
> if ( e )
> set_regs_error(regs, e);
> else
> -set_regs_success(regs, count, 0);
> +set_regs_success(regs, count, fpi_size);
> return true;
> case FFA_RX_RELEASE:
> e = handle_rx_release();
> @@ -1629,10 +1633,11 @@ static bool init_subscribers(struct 
> ffa_partition_info_1_1 *fpi, uint16_t count)
> static bool init_sps(void)
> {
> bool ret = false;
> +uint32_t fpi_size;
> uint32_t count;
> int e;
> 
> -e = ffa_partition_info_get(0, 0, 0, 0, 0, );
> +e = ffa_partition_info_get(0, 0, 0, 0, 0, , _size);
> if ( e )
> {
> printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e);
> -- 
> 2.34.1
> 

Re: [XEN PATCH] xen/arm: ffa: return FFA_RET_NOT_SUPPORTED on unhandled calls

[Bertrand Marquis]

Hi Jens,


> On 13 Dec 2023, at 11:32, Jens Wiklander  wrote:
> 
> Until now has an unsupported FF-A request been reported back with
> ARM_SMCCC_ERR_UNKNOWN_FUNCTION in register x0. A FF-A caller would
> rather expect FFA_ERROR in x0 and FFA_RET_NOT_SUPPORTED in x2 so update
> ffa_handle_call() to return true and with the cpu_user_regs updated.
> 
> Fixes: 38846de2176b ("xen/arm: tee: add a primitive FF-A mediator")
> Signed-off-by: Jens Wiklander 

With the Nit from Michal fixed in the commit message (could be done on commit):
Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 183528d13388..98905fec7967 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -1477,7 +1477,8 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> 
> default:
> gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
> -return false;
> +set_regs_error(regs, FFA_RET_NOT_SUPPORTED);
> +return true;
> }
> }
> 
> -- 
> 2.34.1
> 

Re: [PATCH] MAINTAINERS: Hand over the release manager role to Oleksii Kurochko

[Bertrand Marquis]

> On 8 Dec 2023, at 12:04, Wei Chen  wrote:
> 
> Hi Henry,
> 
> On 2023/12/8 00:20, Henry Wang wrote:
>> I've finished the opportunity to do two releases (4.17 and 4.18)
>> and Oleksii Kurochko has volunteered to be the next release manager.
>> Hand over the role to him by changing the maintainership of the
>> CHANGELOG.md.
>> Signed-off-by: Henry Wang 
>> ---
>>  MAINTAINERS | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 0fcf5a6f36..702032cc12 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -278,7 +278,7 @@ S: Supported
>>  F: xen/drivers/passthrough/arm/smmu-v3.c
>>Change Log
>> -M: Henry Wang 
>> +M: Oleksii Kurochko 
>>  R: Community Manager 
>>  S: Maintained
>>  F: CHANGELOG.md
> 
> I'm proud of your work on the last two Xen releases.
> Thanks for your works!
> 

I am seconding that.

Thanks a lot Henry for the great work you made during those 2 releases.
Cheers
Bertrand

Re: [RFC PATCH] xen/arm: Add emulation of Debug Data Transfer Registers

[Bertrand Marquis]

Hi All,

Sorry for coming back late on this thread.

> On 7 Dec 2023, at 22:41, Stefano Stabellini  wrote:
> 
> On Thu, 7 Dec 2023, Julien Grall wrote:
>> Hi Stefano,
>> 
>> On 05/12/2023 23:21, Stefano Stabellini wrote:
>>> On Tue, 5 Dec 2023, Julien Grall wrote:
 I agree that crashing a guest is bad, but is lying to the domain really
 better? The consequence here is not that bad and hopefully it would be
 fairly
 easy to find. But this is not always the case. So I definitely would place
 a
 half-backed emulation more severe than a guest crash.
>>> 
>>> 
>>> I see where Julien is coming from, but I would go with option two:
>>> "emulate DCC the same way as KVM". That's because I don't think we can
>>> get away with crashing the guest in all cases. Although the issue came
>>> up with a Linux guest, it could have been triggered by a proprietary
>>> operating system that we cannot change, and I think Xen should support
>>> running unmodified operating systems.
>>> 
>>> If we go with a "half-backed emulation" solution, as Julien wrote, then
>>> it is better to be more similar to other hypervisors, that's why I chose
>>> option two instead of option three.
>>> 
>>> But at the same time I recognize the validity of Julien's words and it
>>> makes me wonder if we should have a KCONFIG option or command line
>>> option to switch the Xen behavior. We could use it to gate all the
>>> "half-backed emulation" we do for compatibility.  Something like:
>>> 
>>> config PARTIAL_EMULATION
>>> bool "Partial Emulation"
>>> ---help---
>>>   Enables partial, not spec compliant, emulation of certain
>>> register
>>> interfaces (e.g DCC UART) for guest compatibility. If you disable
>>> this option, Xen will crash the guest if the guest tries to access
>>> interfaces not fully emulated or virtualized.
>>> 
>>> If you enable this option, the guest might misbehave due to non-spec
>>> compliant emulation done by Xen.
>> 
>> As I wrote to Ayan on Matrix today, I am not in favor of the emulation. Yet, 
>> I
>> am not going to oppose (as in Nack it) if the other maintainers agree with 
>> it.
> 
> Thanks for being flexible
> 
> 
>> The KConfig would be nice, the question is whether we want to (security)
>> support such configuration? E.g. could this potentially introduce a security
>> issue in the guest?
> 
> The important question is whether it could introduce a security issue in
> Xen. If we think it wouldn't increase the attack surface significantly
> then I would security support it otherwise not.
> 
> 
>> Regarding the  emulation itself, I actually prefer 3 because at least the
>> Linux drivers will be able to bail out rather than trying to use them.
> 
> I don't have a strong opinion between 2 and 3

Here is my view on it:
- providing a wrong emulation to please guests is not wrong as it might end
up hidding something that will be hard to debug so on that point I agree with
Julien.
- choosing a solution which might just crash a guest without any other solution
than recompiling or modifying xen is not something acceptable if we want Xen
to thrive.

So i would suggest the following solution:
- have a Kconfig to surround this code so that "correct" guests can disable it.
- have a command line option to activate this behavior and turn it off by 
default.
One encountering the problem will have to explicitly set a command line 
parameter
so cannot do this without knowing.
- activate the Kconfig option by default and security support it as it is only 
active if
a command line parameter is passed.

The Kconfig parameter should be more generic so that this could apply to a 
bunch of
registers we would emulate with RAZ/WI so I am happy with that proposal if we 
say
that this must be activated through a command line option passed to Xen at boot.

Regards
Bertrand

Re: [RFC XEN PATCH] xen/arm: ffa: reclaim shared memory on guest destroy

[Bertrand Marquis]

Hi Julien,

Thanks a lot for your review and comment, this is very helpful.

> On 4 Dec 2023, at 20:24, Julien Grall  wrote:
> 
> Hi Jens,
> 
> On 04/12/2023 07:55, Jens Wiklander wrote:
>> When an FF-A enabled guest is destroyed it may leave behind memory
>> shared with SPs. This memory must be reclaimed before it's reused or an
>> SP may make changes to memory used by a new unrelated guest. So when the
>> domain is teared down add FF-A requests to reclaim all remaining shared
>> memory.
>> SPs in the secure world are notified using VM_DESTROYED that a guest has
>> been destroyed. An SP is supposed to relinquish all shared memory to allow
>> reclaiming the memory. The relinquish operation may need to be delayed if
>> the shared memory is for instance part of a DMA operation.
>> If the FF-A memory reclaim request fails, return -ERESTART to retry
>> again. This will effectively block the destruction of the guest until
>> all memory has been reclaimed.
>> Signed-off-by: Jens Wiklander 
>> ---
>> Hi,
>> This patch is a bit crude, but gets the job done. In a well designed
>> system this might even be good enough since the SP or the secure world
>> will let the memory be reclaimed and we can move on. But, if for some
>> reason reclaiming the memory is refused it must not be possible to reuse
>> the memory.
> 
> IIUC, we are trying to harden against a buggy SP. Is that correct?

This is not hardening as this is a possible scenario with a correctly 
implemented SP.
This is valid for the SP to not be able to relinquish the memory directly so we 
have
to take this possibility into account and retry.

What is not expected if for the SP to never release the memory hence the 
possible
"todo" at the end of the code where i think we might have to implement a counter
to bound the possible number of loops but as always the question is how many...

In this case the only solution would be to park the memory as suggested after
but we are not completely sure where hence the RFC.

> 
>> These shared memory ranges are typically quite small compared to the
>> total memory usage of a guest so it would be an improvement if only
>> refused shared memory ranges where set aside from future reuse while the
>> guest was destroyed and other resources made available for reuse. This
>> could be done by for instance assign the refused shared memory ranges
>> to a dummy VM like DOMID_IO.
> 
> I like the idea to use a dummy VM, but I don't think DOMID_IO is right. Once 
> teardown has completed, the domain will stay around until the last reference 
> on all pages are dropped. At this point, the amount of memory left-over is 
> minimum (this is mostly bookeeping in Xen).
> 
> From the userland PoV, the domain will still show-up in the list but tools 
> like "xl list" will show "(null)". They are called zombie domains.
> 
> So I would consider to keep the same domain around. The advantage is you can 
> call "xl destroy" again to retry the operation.

In this scenario the "restart" implementation here is right but how could we 
park the VM as "zombie" instead of busy looping in
the "kill" loop of userland ?

Also we need to release all the memory of the VM but the one shared with the 
SP. 

I will let Jens answer the more implementation questions here after and try to 
help on the more "system" ones.

> 
>> Thanks,
>> Jens
>> ---
>>  xen/arch/arm/tee/ffa.c | 36 
>>  1 file changed, 36 insertions(+)
>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>> index 183528d13388..9c596462a8a2 100644
>> --- a/xen/arch/arm/tee/ffa.c
>> +++ b/xen/arch/arm/tee/ffa.c
>> @@ -1539,6 +1539,7 @@ static bool is_in_subscr_list(const uint16_t *subscr, 
>> uint16_t start,
>>  static int ffa_domain_teardown(struct domain *d)
>>  {
>>  struct ffa_ctx *ctx = d->arch.tee;
>> +struct ffa_shm_mem *shm, *tmp;
>>  unsigned int n;
>>  int32_t res;
>>  @@ -1564,10 +1565,45 @@ static int ffa_domain_teardown(struct domain *d)
>>  printk(XENLOG_ERR "ffa: Failed to report destruction of vm_id 
>> %u to  %u: res %d\n",
>> get_vm_id(d), subscr_vm_destroyed[n], res);
>>  }
>> +/*
>> + * If this function is called again due to -ERESTART below, make sure
>> + * not to send the FFA_MSG_SEND_VM_DESTROYED's.
>> + */
>> +subscr_vm_destroyed_count = 0;
> 
> AFAICT, this variable is global. So wouldn't you effectively break other 
> domain if let say the unmapping error is temporary?
> 
>>if ( ctx->rx )
>>  rxtx_unmap(ctx);
>>  +
>> +list_for_each_entry_safe(shm, tmp, >shm_list, list)
>> +{
>> +register_t handle_hi;
>> +register_t handle_lo;
>> +
>> +uint64_to_regpair(_hi, _lo, shm->handle);
>> +res = ffa_mem_reclaim(handle_lo, handle_hi, 0);
> 
> Is this call expensive? If so, we may need to handle continuation here.

This call should not be expensive in the normal case as memory is reclaimable
so there is no 

Re: [PATCH v3 3/5] arm/dom0less: put dom0less feature code in a separate module

[Bertrand Marquis]

Hi Luca,

> On 13 Nov 2023, at 10:58, Luca Fancellu  wrote:
> 
>> 
>>> 
>>> The functions allocate_static_memory and assign_static_memory_11
>>> are now externally visible, so put their declarations into
>>> domain_build.h and move the #else and stub definition in the header
>>> as well.
>>> 
>>> Move is_dom0less_mode from setup.c to dom0less-build.c and make it
>>> externally visible.
>>> 
>>> The function allocate_bank_memory is used only by dom0less code
>>> at the moment, but it's been decided to leave it in domain_build.c
>>> in case that in the future the dom0 code can use it.
>>> 
>>> Where spotted, fix code style issues.
>>> 
>>> No functional change is intended.
>>> 
>>> Signed-off-by: Luca Fancellu 
>>> ---
>>> Changes from v2:
>>> - move allocate_bank_memory back in domain_build.c, remove header
>>>  from dom0less-build.c.
>> I can see you removed the copyright from .c but .h still has it. This also
>> applies to other newly introduced files that were subject only to code 
>> movement.
> 
> I’ve just read again your comment, I pushed the v4 but removing the header 
> only from
> dom0less-build.h.
> I left the header in the other static-* because that I think was code 
> produced by Arm,
> please let me know your thoughts about that (you and the Arm maintainers)

Even if true, adding the copyright after is a bit odd.
I do not think this is code on which the copyright really has impact so I would 
not add it during the move.

Cheers
Bertrand

> 
> Cheers,
> Luca
> 

Re: [PATCH] xenoprof: move asm/ include

[Bertrand Marquis]

Hi Jan,

> On 30 Oct 2023, at 14:19, Jan Beulich  wrote:
> 
> There's no need for xen/xenoprof.h to include the arch header when the
> respective config option is off. The only compensation needed is for
> svm.c to explicitly include the arch header instead of the common one
> (matching what vmx.c and traps.c do).
> 
> With that Arm's header can be deleted, and neither RISC-V nor PPC will
> need to introduce one.
> 
> While there also adjust and move the (prior) inclusion of inttypes.h.
> 
> Signed-off-by: Jan Beulich 

Always nice to remove a useless empty file :-)

For the arm part:

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> 
> --- a/xen/arch/arm/include/asm/xenoprof.h
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -#ifndef __ASM_XENOPROF_H__
> -#define __ASM_XENOPROF_H__
> -
> -#endif /* __ASM_XENOPROF_H__ */
> -/*
> - * Local variables:
> - * mode: C
> - * c-file-style: "BSD"
> - * c-basic-offset: 4
> - * indent-tabs-mode: nil
> - * End:
> - */
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -12,7 +12,6 @@
> #include 
> #include 
> #include 
> -#include 
> 
> #include 
> #include 
> @@ -38,6 +37,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> 
> --- a/xen/include/xen/xenoprof.h
> +++ b/xen/include/xen/xenoprof.h
> @@ -10,15 +10,15 @@
> #ifndef __XEN_XENOPROF_H__
> #define __XEN_XENOPROF_H__
> 
> -#include 
> -#include 
> -
> #define PMU_OWNER_NONE  0
> #define PMU_OWNER_XENOPROF  1
> #define PMU_OWNER_HVM   2
> 
> #ifdef CONFIG_XENOPROF
> 
> +#include 
> +#include 
> +
> struct domain;
> struct vcpu;
> struct cpu_user_regs;

Re: [PATCH] arch: drop get_processor_id()

[Bertrand Marquis]

Hi Jan,

> On 30 Oct 2023, at 14:29, Jan Beulich  wrote:
> 
> smp_processor_id() is what we commonly use; there's no need for it to
> have an alias.
> 
> Signed-off-by: Jan Beulich 

For the arm part:

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> 
> --- a/xen/arch/arm/include/asm/current.h
> +++ b/xen/arch/arm/include/asm/current.h
> @@ -53,7 +53,7 @@ static inline struct cpu_info *get_cpu_i
> 
> DECLARE_PER_CPU(unsigned int, cpu_id);
> 
> -#define get_processor_id() this_cpu(cpu_id)
> +#define smp_processor_id() this_cpu(cpu_id)
> #define set_processor_id(id)\
> do {\
> WRITE_SYSREG(__per_cpu_offset[(id)], TPIDR_EL2);\
> --- a/xen/arch/arm/include/asm/smp.h
> +++ b/xen/arch/arm/include/asm/smp.h
> @@ -11,8 +11,6 @@ DECLARE_PER_CPU(cpumask_var_t, cpu_core_
> 
> #define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
> 
> -#define smp_processor_id() get_processor_id()
> -
> /*
>  * Do we, for platform reasons, need to actually keep CPUs online when we
>  * would otherwise prefer them to be off?
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -401,7 +401,7 @@ void start_secondary(void)
> /* Shut down the current CPU */
> void __cpu_disable(void)
> {
> -unsigned int cpu = get_processor_id();
> +unsigned int cpu = smp_processor_id();
> 
> local_irq_disable();
> gic_disable_cpu();
> --- a/xen/arch/x86/include/asm/current.h
> +++ b/xen/arch/x86/include/asm/current.h
> @@ -99,7 +99,7 @@ static inline struct cpu_info *get_cpu_i
> #define set_current(vcpu) (get_cpu_info()->current_vcpu = (vcpu))
> #define current   (get_current())
> 
> -#define get_processor_id()(get_cpu_info()->processor_id)
> +#define smp_processor_id()(get_cpu_info()->processor_id)
> #define guest_cpu_user_regs() (_cpu_info()->guest_cpu_user_regs)
> 
> /*
> --- a/xen/arch/x86/include/asm/smp.h
> +++ b/xen/arch/x86/include/asm/smp.h
> @@ -48,13 +48,6 @@ extern void cpu_exit_clear(unsigned int
> extern void cpu_uninit(unsigned int cpu);
> int cpu_add(uint32_t apic_id, uint32_t acpi_id, uint32_t pxm);
> 
> -/*
> - * This function is needed by all SMP systems. It must _always_ be valid
> - * from the initial startup. We map APIC_BASE very early in page_setup(),
> - * so this is correct in the x86 case.
> - */
> -#define smp_processor_id() get_processor_id()
> -
> void __stop_this_cpu(void);
> 
> long cf_check cpu_up_helper(void *data);
> --- a/xen/arch/x86/mm/mm-locks.h
> +++ b/xen/arch/x86/mm/mm-locks.h
> @@ -122,7 +122,7 @@ static inline void mm_rwlock_init(mm_rwl
> 
> static inline int mm_write_locked_by_me(mm_rwlock_t *l)
> {
> -return (l->locker == get_processor_id());
> +return (l->locker == smp_processor_id());
> }
> 
> static inline void _mm_write_lock(const struct domain *d, mm_rwlock_t *l,
> @@ -132,7 +132,7 @@ static inline void _mm_write_lock(const
> {
> _check_lock_level(d, level);
> percpu_write_lock(p2m_percpu_rwlock, >lock);
> -l->locker = get_processor_id();
> +l->locker = smp_processor_id();
> l->locker_function = func;
> l->unlock_level = _get_lock_level();
> _set_lock_level(_lock_level(d, level));

Re: [PATCH for-4.19] xen/arm64: domctl: Avoid unreachable code in subarch_do_domctl()

[Bertrand Marquis]

Hi Julien,

> On 23 Oct 2023, at 19:52, Julien Grall  wrote:
> 
> From: Julien Grall 
> 
> The 'break' the XEN_DOMCTL_set_address_size is unreachable and tools
> like Eclair will report as a violation of Misra Rule 2.1.
> 
> Furthermore, the nested switch is not very easy to read. So move
> out the nested switch in a separate function to improve the
> readability and hopefully address the MISRA violation.
> 
> Reported-by: Nicola Vetrini 
> Signed-off-by: Julien Grall 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> 
> ---
> 
> Only compiled tested. Waiting for the CI to confirm there is no
> regression.
> ---
> xen/arch/arm/arm64/domctl.c | 34 +++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> index 14fc622e9956..8720d126c97d 100644
> --- a/xen/arch/arm/arm64/domctl.c
> +++ b/xen/arch/arm/arm64/domctl.c
> @@ -33,27 +33,31 @@ static long switch_mode(struct domain *d, enum 
> domain_type type)
> return 0;
> }
> 
> +static long set_address_size(struct domain *d, uint32_t address_size)
> +{
> +switch ( address_size )
> +{
> +case 32:
> +if ( !cpu_has_el1_32 )
> +return -EINVAL;
> +/* SVE is not supported for 32 bit domain */
> +if ( is_sve_domain(d) )
> +return -EINVAL;
> +return switch_mode(d, DOMAIN_32BIT);
> +case 64:
> +return switch_mode(d, DOMAIN_64BIT);
> +default:
> +return -EINVAL;
> +}
> +}
> +
> long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
> {
> switch ( domctl->cmd )
> {
> case XEN_DOMCTL_set_address_size:
> -switch ( domctl->u.address_size.size )
> -{
> -case 32:
> -if ( !cpu_has_el1_32 )
> -return -EINVAL;
> -/* SVE is not supported for 32 bit domain */
> -if ( is_sve_domain(d) )
> -return -EINVAL;
> -return switch_mode(d, DOMAIN_32BIT);
> -case 64:
> -return switch_mode(d, DOMAIN_64BIT);
> -default:
> -return -EINVAL;
> -}
> -break;
> +return set_address_size(d, domctl->u.address_size.size);
> 
> default:
> return -ENOSYS;
> -- 
> 2.40.1
> 
> 

Re: [PATCH for-4.19 v2] docs/arm: Document where Xen should be loaded in memory

[Bertrand Marquis]

Hi Julien,

> On 24 Oct 2023, at 12:28, Julien Grall  wrote:
> 
> From: Julien Grall 
> 
> In commit 9d267c049d92 ("xen/arm64: Rework the memory layout"),
> we decided to require Xen to be loaded below 2 TiB to simplify
> the logic to enable the MMU. The limit was decided based on
> how known platform boot plus some slack.
> 
> We had a recent report that this is not sufficient on the AVA
> platform with a old firmware [1]. But the restriction is not
> going to change in Xen 4.18. So document the limit clearly
> in docs/misc/arm/booting.txt.
> 
> [1] https://lore.kernel.org/20231013122658.1270506-3-leo@linaro.org
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Michal Orzel 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> 
> ---
> 
>Changes in v2:
>- The limit is 2 TiB no 5
>- Remove unnecessary sentence in the docs
>- Add missing link
>- Add Michal's reviewed-by
> 
> I couldn't find a nice way to document it in SUPPORT.md. So I decided
> to only document the restrict in docs/misc/arm/booting.txt for now.
> 
> I also couldn't find any way from GRUB/UEFI (I didn't look much) to
> specify the loading address.
> ---
> docs/misc/arm/booting.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index 02f7bb65ec6d..547f58a7d981 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -21,7 +21,9 @@ The exceptions to this on 32-bit ARM are as follows:
>  zImage protocol should still be used and not the stricter "raw
>  (non-zImage)" protocol described in arm/Booting.
> 
> -There are no exception on 64-bit ARM.
> +The exceptions to this on 64-bit ARM are as follows:
> +
> + Xen binary should be loaded in memory below 2 TiB.
> 
> Booting Guests
> --
> -- 
> 2.40.1
> 

Re: [PATCH] MAINTAINERS: make Michal Orzel ARM Maintainer

[Bertrand Marquis]

Hi Stefano,

> On 23 Oct 2023, at 22:56, Stefano Stabellini  wrote:
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f61b5a32a1..a5a5f2bffb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -246,6 +246,7 @@ ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
> M: Stefano Stabellini 
> M: Julien Grall 
> M: Bertrand Marquis 
> +M: Michal Orzel 
> R: Volodymyr Babchuk 
> S: Supported
> L: xen-devel@lists.xenproject.org
> -- 
> 2.25.1
> 

Re: [XEN PATCH v2] arm/cpufeature: address violations of MISRA C:2012 Rule 8.2

[Bertrand Marquis]

Hi Frederico,

> On 18 Oct 2023, at 14:50, Federico Serafini  
> wrote:
> 
> Add missing parameter names. No functional change.
> 
> Signed-off-by: Federico Serafini 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes in v2:
> - fixed names.
> ---
> xen/arch/arm/include/asm/cpufeature.h | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/cpufeature.h 
> b/xen/arch/arm/include/asm/cpufeature.h
> index 8011076b8c..c95582044a 100644
> --- a/xen/arch/arm/include/asm/cpufeature.h
> +++ b/xen/arch/arm/include/asm/cpufeature.h
> @@ -127,8 +127,8 @@ static inline void cpus_set_cap(unsigned int num)
> struct arm_cpu_capabilities {
> const char *desc;
> u16 capability;
> -bool (*matches)(const struct arm_cpu_capabilities *);
> -int (*enable)(void *); /* Called on every active CPUs */
> +bool (*matches)(const struct arm_cpu_capabilities *entry);
> +int (*enable)(void *data); /* Called on every active CPUs */
> union {
> struct {/* To be used for eratum handling only */
> u32 midr_model;
> @@ -448,10 +448,10 @@ struct cpuinfo_arm {
> 
> extern struct cpuinfo_arm system_cpuinfo;
> 
> -extern void identify_cpu(struct cpuinfo_arm *);
> +extern void identify_cpu(struct cpuinfo_arm *c);
> 
> #ifdef CONFIG_ARM_64
> -extern void update_system_features(const struct cpuinfo_arm *);
> +extern void update_system_features(const struct cpuinfo_arm *new);
> #else
> static inline void update_system_features(const struct cpuinfo_arm *cpuinfo)
> {
> -- 
> 2.34.1
> 

Re: [PATCH v4 2/2] xen/arm: Enlarge identity map space to 10TB

[Bertrand Marquis]

> On 16 Oct 2023, at 17:31, Julien Grall  wrote:
> 
> 
> 
> On 16/10/2023 16:07, Bertrand Marquis wrote:
>> Hi,
>>> On 16 Oct 2023, at 16:46, Julien Grall  wrote:
>>> 
>>> CC Henry
>>> 
>>> Hi Alexey,
>>> 
>>> On 16/10/2023 15:24, Alexey Klimov wrote:
>>>> On Mon, 16 Oct 2023 at 15:13, Luca Fancellu  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 16 Oct 2023, at 15:00, Bertrand Marquis  
>>>>>> wrote:
>>>>>> 
>>>>>> Hi
>>>>>> 
>>>>>> +Luca and Rahul
>>>>>> 
>>>>>>> On 16 Oct 2023, at 15:54, Julien Grall  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 16/10/2023 09:44, Michal Orzel wrote:
>>>>>>>> Hi,
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>>> On 13/10/2023 14:26, Leo Yan wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 
>>>>>>>>> cores),
>>>>>>>>> the physical memory regions are:
>>>>>>>>> 
>>>>>>>>>  DRAM memory regions:
>>>>>>>>>Node[0] Region[0]: 0x8000 - 0x
>>>>>>>>>Node[0] Region[1]: 0x0800 - 0x08007fff
>>>>>>>>>Node[0] Region[2]: 0x0801 - 0x0807
>>>>>>>>> 
>>>>>>>>> The UEFI loads Xen hypervisor and DTB into the high memory, the kernel
>>>>>>>>> and ramdisk images are loaded into the low memory space:
>>>>>>>>> 
>>>>>>>>>  (XEN) MODULE[0]: 0807f6df - 0807f6f3e000 Xen
>>>>>>>>>  (XEN) MODULE[1]: 0807f8054000 - 0807f8056000 Device Tree
>>>>>>>>>  (XEN) MODULE[2]: fa834000 - fc5de1d5 Ramdisk
>>>>>>>>>  (XEN) MODULE[3]: fc5df000 - ffb3f810 Kernel
>>>>>>>>> 
>>>>>>>>> In this case, the Xen binary is loaded above 8TB, which exceeds the
>>>>>>>>> maximum supported identity map space of 2TB in Xen. Consequently, the
>>>>>>>>> system fails to boot.
>>>>>>>>> 
>>>>>>>>> This patch enlarges identity map space to 10TB, allowing module 
>>>>>>>>> loading
>>>>>>>>> within the range of [0x0 .. 0x09ff__].
>>>>>>>>> 
>>>>>>>>> Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to 
>>>>>>>>> prepare/enable/disable")
>>>>>>>> I don't think a fixes tag applies here given that 2TB was just a 
>>>>>>>> number we believed is enough
>>>>>>>> and all of this is platform dependent.
>>>>>>>> This can be dropped on commit if committer agrees
>>>>>>> Xen may have booted on that platform before hand. So this would be 
>>>>>>> considered a regression and therefore a tag would be warrant.
>>>>>>> 
>>>>>>> AFAICT, the commit is only present on the upcoming 4.18. So the 
>>>>>>> question is whether Xen 4.17 booted out-of-the-box on ADLink? If the 
>>>>>>> answer is yes, then we need to add a Fixes tag. But the correct one 
>>>>>>> would be
>>>>>>> 
>>>>>> 
>>>>>> @Rahul or Luca: could you give an answer here ?
>>>>>> I know you used Xen on an AVA platform but was it booting out of the box 
>>>>>> ?
>>>>> 
>>>>> I can’t say for Xen 4.17, but our nightly job has run successfully on AVA 
>>>>> for the commit 730406ab81094115d9fb5ca00ba8d53cec1279b3
>>>>> (docs/misra: add deviations.rst to document additional deviations.)
>>>>> 
>>>>> We are not applying any patch for it to run on AVA.
>>>> Most likely it is because your UEFI/BIOS firmware is 2.x, for instance
>>>> 2.04.100.07.
>>>> This fix if for AVA machine with older UEFI firmware 1.07.300.03.
>>> 
>&g

Re: [PATCH v4 2/2] xen/arm: Enlarge identity map space to 10TB

[Bertrand Marquis]

Hi,

> On 16 Oct 2023, at 16:46, Julien Grall  wrote:
> 
> CC Henry
> 
> Hi Alexey,
> 
> On 16/10/2023 15:24, Alexey Klimov wrote:
>> On Mon, 16 Oct 2023 at 15:13, Luca Fancellu  wrote:
>>> 
>>> 
>>> 
>>>> On 16 Oct 2023, at 15:00, Bertrand Marquis  
>>>> wrote:
>>>> 
>>>> Hi
>>>> 
>>>> +Luca and Rahul
>>>> 
>>>>> On 16 Oct 2023, at 15:54, Julien Grall  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 16/10/2023 09:44, Michal Orzel wrote:
>>>>>> Hi,
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On 13/10/2023 14:26, Leo Yan wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
>>>>>>> the physical memory regions are:
>>>>>>> 
>>>>>>>  DRAM memory regions:
>>>>>>>Node[0] Region[0]: 0x8000 - 0x
>>>>>>>Node[0] Region[1]: 0x0800 - 0x08007fff
>>>>>>>Node[0] Region[2]: 0x0801 - 0x0807
>>>>>>> 
>>>>>>> The UEFI loads Xen hypervisor and DTB into the high memory, the kernel
>>>>>>> and ramdisk images are loaded into the low memory space:
>>>>>>> 
>>>>>>>  (XEN) MODULE[0]: 0807f6df - 0807f6f3e000 Xen
>>>>>>>  (XEN) MODULE[1]: 0807f8054000 - 0807f8056000 Device Tree
>>>>>>>  (XEN) MODULE[2]: fa834000 - fc5de1d5 Ramdisk
>>>>>>>  (XEN) MODULE[3]: fc5df000 - ffb3f810 Kernel
>>>>>>> 
>>>>>>> In this case, the Xen binary is loaded above 8TB, which exceeds the
>>>>>>> maximum supported identity map space of 2TB in Xen. Consequently, the
>>>>>>> system fails to boot.
>>>>>>> 
>>>>>>> This patch enlarges identity map space to 10TB, allowing module loading
>>>>>>> within the range of [0x0 .. 0x09ff__].
>>>>>>> 
>>>>>>> Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to 
>>>>>>> prepare/enable/disable")
>>>>>> I don't think a fixes tag applies here given that 2TB was just a number 
>>>>>> we believed is enough
>>>>>> and all of this is platform dependent.
>>>>>> This can be dropped on commit if committer agrees
>>>>> Xen may have booted on that platform before hand. So this would be 
>>>>> considered a regression and therefore a tag would be warrant.
>>>>> 
>>>>> AFAICT, the commit is only present on the upcoming 4.18. So the question 
>>>>> is whether Xen 4.17 booted out-of-the-box on ADLink? If the answer is 
>>>>> yes, then we need to add a Fixes tag. But the correct one would be
>>>>> 
>>>> 
>>>> @Rahul or Luca: could you give an answer here ?
>>>> I know you used Xen on an AVA platform but was it booting out of the box ?
>>> 
>>> I can’t say for Xen 4.17, but our nightly job has run successfully on AVA 
>>> for the commit 730406ab81094115d9fb5ca00ba8d53cec1279b3
>>> (docs/misra: add deviations.rst to document additional deviations.)
>>> 
>>> We are not applying any patch for it to run on AVA.
>> Most likely it is because your UEFI/BIOS firmware is 2.x, for instance
>> 2.04.100.07.
>> This fix if for AVA machine with older UEFI firmware 1.07.300.03.
> 
> OOI, why not updating your firmware? I was expecting that it would also 
> contain other critical fixes.
> 
> With this in mind, I am now more in two mind to ask to merge this patch in 
> Xen 4.18. On one hand, I understand it will help to boot on AVA machine with 
> an older firmware. But on the other hand this is changing the memory layout 
> quite late in the release. The risk seems limited because Xen is not loaded 
> at the top of the virtual address space (there is the directmap afterwards).
> 
> Henry (as the release manager) and others, any opinions?

With the new information, I think it should be stated that it is fixing an 
issue on AVA platforms using an old firmware and platforms with and up-to-date 
firmware are not impacted.
It is an important information to keep in mind that this is not a fix to be 
backported for example (and for me the fixes tag should not be kept).

On whether or not it should go in the release, I am not quite sure that making 
a change in the layout at that stage is a good idea unless it is fixing a 
critical issue (which is not the case here).
So i would vote no but not go against if someone argue to have it in.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v4 2/2] xen/arm: Enlarge identity map space to 10TB

[Bertrand Marquis]

Hi
 
+Luca and Rahul

> On 16 Oct 2023, at 15:54, Julien Grall  wrote:
> 
> 
> 
> On 16/10/2023 09:44, Michal Orzel wrote:
>> Hi,
> 
> Hi,
> 
>> On 13/10/2023 14:26, Leo Yan wrote:
>>> 
>>> 
>>> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
>>> the physical memory regions are:
>>> 
>>>   DRAM memory regions:
>>> Node[0] Region[0]: 0x8000 - 0x
>>> Node[0] Region[1]: 0x0800 - 0x08007fff
>>> Node[0] Region[2]: 0x0801 - 0x0807
>>> 
>>> The UEFI loads Xen hypervisor and DTB into the high memory, the kernel
>>> and ramdisk images are loaded into the low memory space:
>>> 
>>>   (XEN) MODULE[0]: 0807f6df - 0807f6f3e000 Xen
>>>   (XEN) MODULE[1]: 0807f8054000 - 0807f8056000 Device Tree
>>>   (XEN) MODULE[2]: fa834000 - fc5de1d5 Ramdisk
>>>   (XEN) MODULE[3]: fc5df000 - ffb3f810 Kernel
>>> 
>>> In this case, the Xen binary is loaded above 8TB, which exceeds the
>>> maximum supported identity map space of 2TB in Xen. Consequently, the
>>> system fails to boot.
>>> 
>>> This patch enlarges identity map space to 10TB, allowing module loading
>>> within the range of [0x0 .. 0x09ff__].
>>> 
>>> Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to 
>>> prepare/enable/disable")
>> I don't think a fixes tag applies here given that 2TB was just a number we 
>> believed is enough
>> and all of this is platform dependent.
>> This can be dropped on commit if committer agrees
> Xen may have booted on that platform before hand. So this would be considered 
> a regression and therefore a tag would be warrant.
> 
> AFAICT, the commit is only present on the upcoming 4.18. So the question is 
> whether Xen 4.17 booted out-of-the-box on ADLink? If the answer is yes, then 
> we need to add a Fixes tag. But the correct one would be
> 

@Rahul or Luca: could you give an answer here ?
I know you used Xen on an AVA platform but was it booting out of the box ?

> 1c78d76b67e1 ("xen/arm64: mm: Introduce helpers to prepare/enable/disable 
> the identity mapping").
> 
> We would also need to consider it as a candidate for Xen 4.18 because we 
> would regress boot on ADLink.

Ack

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [XEN PATCH 10/10] arm/smmu: address violation of MISRA C:2012 Rule 8.2

[Bertrand Marquis]

Hi Julien,

> On 16 Oct 2023, at 15:38, Julien Grall  wrote:
> 
> 
> 
> On 16/10/2023 14:31, Bertrand Marquis wrote:
>> Hi Julien,
> 
> Hi Bertrand,
> 
>>> On 16 Oct 2023, at 11:07, Julien Grall  wrote:
>>> 
>>> Hi,
>>> 
>>> On 13/10/2023 16:24, Federico Serafini wrote:
>>>> Add missing parameter names, no functional change.
>>>> Signed-off-by: Federico Serafini 
>>>> ---
>>>>  xen/drivers/passthrough/arm/smmu.c | 6 +++---
>>> 
>>> This file is using the Linux coding style because it is imported from 
>>> Linux. I was under the impression we would exclude such file for now.
>>> 
>>> Looking at exclude-list.json, it doesn't seem to be present. I think this 
>>> patch should be replaced with adding a line in execlude-list.json.
>> I think that during one of the discussions we said that this file already 
>> deviated quite a lot from the status in Linux and we wanted to turn it to 
>> Xen coding style in the future hence it is not listed in the exclude file.
> AFAIK the SMMUv{1, 2} code didn't deviate very much from Linux. I can't tell 
> about the SMMUv3.

True that i had the v3 code in mind, we might not want to do that for v1/2 you 
are right.

> 
>> At the end having a working smmu might be critical in a safety context so it 
>> will make sense to also check this part of xen.
> I don't buy this argument right now. We have files in exclude-lists.json that 
> I would consider critical for Xen to run (e.g. common/bitmap.c, 
> common/libfdt). So if you want to use this argument then we need to move 
> critical components of Xen out of the exclusion list.

I am sure we will at some point for runtime code but we cannot do everything on 
the first shot.
I was not meaning to do that now but that it is something to consider.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v4 2/2] xen/arm: Enlarge identity map space to 10TB

[Bertrand Marquis]

Hi,

> On 13 Oct 2023, at 14:26, Leo Yan  wrote:
> 
> On ADLink AVA platform (Ampere Altra SoC with 32 Arm Neoverse N1 cores),
> the physical memory regions are:
> 
>  DRAM memory regions:
>Node[0] Region[0]: 0x8000 - 0x
>Node[0] Region[1]: 0x0800 - 0x08007fff
>Node[0] Region[2]: 0x0801 - 0x0807
> 
> The UEFI loads Xen hypervisor and DTB into the high memory, the kernel
> and ramdisk images are loaded into the low memory space:
> 
>  (XEN) MODULE[0]: 0807f6df - 0807f6f3e000 Xen
>  (XEN) MODULE[1]: 0807f8054000 - 0807f8056000 Device Tree
>  (XEN) MODULE[2]: fa834000 - fc5de1d5 Ramdisk
>  (XEN) MODULE[3]: fc5df000 - ffb3f810 Kernel
> 
> In this case, the Xen binary is loaded above 8TB, which exceeds the
> maximum supported identity map space of 2TB in Xen. Consequently, the
> system fails to boot.
> 
> This patch enlarges identity map space to 10TB, allowing module loading
> within the range of [0x0 .. 0x09ff__].
> 
> Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to 
> prepare/enable/disable")

I agree with Michal here, this is not a fix so this should be removed (can be 
done
on commit).

> Reported-by: Alexey Klimov 
> Signed-off-by: Leo Yan 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/arm64/mm.c   | 6 --
> xen/arch/arm/include/asm/mmu/layout.h | 8 
> 2 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/mm.c b/xen/arch/arm/arm64/mm.c
> index 78b7c7eb00..cb69df0661 100644
> --- a/xen/arch/arm/arm64/mm.c
> +++ b/xen/arch/arm/arm64/mm.c
> @@ -41,7 +41,8 @@ static void __init prepare_boot_identity_mapping(void)
> clear_page(boot_third_id);
> 
> if ( id_offsets[0] >= IDENTITY_MAPPING_AREA_NR_L0 )
> -panic("Cannot handle ID mapping above 2TB\n");
> +panic("Cannot handle ID mapping above %uTB\n",
> +  IDENTITY_MAPPING_AREA_NR_L0 >> 1);
> 
> /* Link first ID table */
> pte = mfn_to_xen_entry(virt_to_mfn(boot_first_id), MT_NORMAL);
> @@ -74,7 +75,8 @@ static void __init prepare_runtime_identity_mapping(void)
> DECLARE_OFFSETS(id_offsets, id_addr);
> 
> if ( id_offsets[0] >= IDENTITY_MAPPING_AREA_NR_L0 )
> -panic("Cannot handle ID mapping above 2TB\n");
> +panic("Cannot handle ID mapping above %uTB\n",
> +  IDENTITY_MAPPING_AREA_NR_L0 >> 1);
> 
> /* Link first ID table */
> pte = pte_of_xenaddr((vaddr_t)xen_first_id);
> diff --git a/xen/arch/arm/include/asm/mmu/layout.h 
> b/xen/arch/arm/include/asm/mmu/layout.h
> index 2cb2382fbf..eac7eef885 100644
> --- a/xen/arch/arm/include/asm/mmu/layout.h
> +++ b/xen/arch/arm/include/asm/mmu/layout.h
> @@ -19,11 +19,11 @@
>  *   2G -   4G   Domheap: on-demand-mapped
>  *
>  * ARM64 layout:
> - * 0x - 0x01ff (2TB, L0 slots [0..3])
> + * 0x - 0x09ff (10TB, L0 slots [0..19])
>  *
>  *  Reserved to identity map Xen
>  *
> - * 0x0200 - 0x027f (512GB, L0 slot [4])
> + * 0x0a00 - 0x0a7f (512GB, L0 slot [20])
>  *  (Relative offsets)
>  *   0  -   2M   Unmapped
>  *   2M -  10M   Xen text, data, bss
> @@ -35,7 +35,7 @@
>  *
>  *  32G -  64G   Frametable: 56 bytes per page for 2TB of RAM
>  *
> - * 0x0280 - 0x7fff (125TB, L0 slots [5..255])
> + * 0x0a80 - 0x7fff (512GB+117TB, L0 slots [21..255])
>  *  Unused
>  *
>  * 0x8000 - 0x84ff (5TB, L0 slots [256..265])
> @@ -49,7 +49,7 @@
> #define XEN_VIRT_START  _AT(vaddr_t, MB(2))
> #else
> 
> -#define IDENTITY_MAPPING_AREA_NR_L0 4
> +#define IDENTITY_MAPPING_AREA_NR_L0 20
> #define XEN_VM_MAPPING  SLOT0(IDENTITY_MAPPING_AREA_NR_L0)
> 
> #define SLOT0_ENTRY_BITS  39
> -- 
> 2.39.2
> 

Re: [XEN PATCH 10/10] arm/smmu: address violation of MISRA C:2012 Rule 8.2

[Bertrand Marquis]

Hi Julien,

> On 16 Oct 2023, at 11:07, Julien Grall  wrote:
> 
> Hi,
> 
> On 13/10/2023 16:24, Federico Serafini wrote:
>> Add missing parameter names, no functional change.
>> Signed-off-by: Federico Serafini 
>> ---
>>  xen/drivers/passthrough/arm/smmu.c | 6 +++---
> 
> This file is using the Linux coding style because it is imported from Linux. 
> I was under the impression we would exclude such file for now.
> 
> Looking at exclude-list.json, it doesn't seem to be present. I think this 
> patch should be replaced with adding a line in execlude-list.json.

I think that during one of the discussions we said that this file already 
deviated quite a lot from the status in Linux and we wanted to turn it to Xen 
coding style in the future hence it is not listed in the exclude file.
At the end having a working smmu might be critical in a safety context so it 
will make sense to also check this part of xen.

@Rahul: do you agree ?

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [for-4.18][PATCH] xen/arm: Check return code from recursive calls to scan_pfdt_node()

[Bertrand Marquis]

Hi Michal,

> On 16 Oct 2023, at 14:45, Michal Orzel  wrote:
> 
> At the moment, we do not check a return code from scan_pfdt_node()
> called recursively. This means that any issue that may occur while
> parsing and copying the passthrough nodes is hidden and Xen continues
> to boot a domain despite errors. This may lead to incorrect device tree
> generation and various guest issues (e.g. trap on attempt to access MMIO
> not mapped in P2M). Fix it.
> 
> Fixes: 669ecdf8d6cd ("xen/arm: copy dtb fragment to guest dtb")
> Signed-off-by: Michal Orzel 

Good finding :-)

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> @Henry:
> This is a bug fix, so I think we should have it in 4.18 given the possible
> consequences I described in the commit msg. I don't see any risks as this 
> change
> only checks the return code for an error.
> ---
> xen/arch/arm/domain_build.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 24c9019cc43c..49792dd590ee 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2872,8 +2872,11 @@ static int __init scan_pfdt_node(struct kernel_info 
> *kinfo, const void *pfdt,
> node_next = fdt_first_subnode(pfdt, nodeoff);
> while ( node_next > 0 )
> {
> -scan_pfdt_node(kinfo, pfdt, node_next, address_cells, size_cells,
> -   scan_passthrough_prop);
> +rc = scan_pfdt_node(kinfo, pfdt, node_next, address_cells, 
> size_cells,
> +scan_passthrough_prop);
> +if ( rc )
> +return rc;
> +
> node_next = fdt_next_subnode(pfdt, node_next);
> }
> 
> -- 
> 2.25.1
> 

Re: [PATCH v2 3/5] arm/dom0less: put dom0less feature code in a separate module

[Bertrand Marquis]

Hi,

> On 2 Oct 2023, at 10:26, Julien Grall  wrote:
> 
> Hi Stefano,
> 
> On 29/09/2023 20:48, Stefano Stabellini wrote:
>> On Fri, 29 Sep 2023, Luca Fancellu wrote:
 On 29 Sep 2023, at 01:33, Stefano Stabellini  
 wrote:
 
 On Wed, 27 Sep 2023, Luca Fancellu wrote:
> Currently the dom0less feature code is mostly inside domain_build.c
> and setup.c, it is a feature that may not be useful to everyone so
> put the code in a different compilation module in order to make it
> easier to disable the feature in the future.
> 
> Move gic_interrupt_t in domain_build.h to use it with the function
> declaration, move its comment above the declaration.
> 
> The following functions are now visible externally from domain_build
> because they are used also from the dom0less-build module:
> - get_allocation_size
> - set_interrupt
> - domain_fdt_begin_node
> - make_memory_node
> - make_resv_memory_node
> - make_hypervisor_node
> - make_psci_node
> - make_cpus_node
> - make_timer_node
> - handle_device_interrupts
> - construct_domain
> - process_shm
> 
> The functions allocate_static_memory and assign_static_memory_11
> are now externally visible, so put their declarations into
> domain_build.h and move the #else and stub definition in the header
> as well.
> 
> Move is_dom0less_mode from setup.c to dom0less-build.c and make it
> externally visible.
> 
> Where spotted, fix code style issues.
> 
> No functional change is intended.
> 
> Signed-off-by: Luca Fancellu 
 
 This is great! A couple of questions.
 
 Why was allocate_static_memory not moved to dom0less-build.c ?
>>> 
>>> My aim is to decouple the features, so in patch 4 we move (just once as 
>>> Julien suggested)
>>> the static memory code on a module on its own, because we can have a guest 
>>> booted with
>>> dom0less feature but having it with static memory is optional.
>> OK
 Would it make sense to also move construct_dom0 to dom0less-build.c
 given the similarities with construct_domU? I am not sure about this.
 
>>> 
>>> We can’t do that because the final goal of this serie is to have a Kconfig 
>>> disabling dom0less,
>>> so in that case we will end up removing from the compilation also 
>>> construct_dom0.
>> OK. Probably we can't do much better than this.
>> One more question on the code movement, and I would also like Julien and
>> Bertrand to express their opinions on this.
>> Given that code movement is painful from a git history perspective, and
>> given that we have to move dom0less code to xen/common anyway to make
>> it available to RISC-V and also x86, could we do it in one shot here?
> 
> Looking at the name of the functions, I would expect that we would need 
> another code movement in the future to move back Arm specific function under 
> arch/arm/. So we would end up with two code movement as well.
> 
> I would prefer if we wait until RISC-V/x86 needs it so we don't unnecessarily 
> move Arm specific code in common/.

I agree with Julien here.
Moving the code now will mean moving part of it back in arm in the future once 
we have a second user of this.
I would rather wait for the need to come so that we do this cleanly.

Also using hyperlaunch name now would be weird as there was no agreement on the 
naming (as far as I know) so far.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3] docs/misra: add rule 2.1 exceptions

[Bertrand Marquis]

> On 28 Sep 2023, at 02:40, Stefano Stabellini  wrote:
> 
> On Wed, 27 Sep 2023, Bertrand Marquis wrote:
>>> On 27 Sep 2023, at 09:53, Nicola Vetrini  wrote:
>>> 
>>>>>> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>>>>>> index 695d2fa1f1..2a8527cacc 100644
>>>>>> --- a/xen/arch/arm/psci.c
>>>>>> +++ b/xen/arch/arm/psci.c
>>>>>> @@ -59,6 +59,7 @@ void call_psci_cpu_off(void)
>>>>>>  }
>>>>>>  }
>>>>>>  +/* SAF-2-safe */
>>>>> I think any use of SAF-2-safe should be accompanied with an attribute...
>>>>>>  void call_psci_system_off(void)
>>>>> ... noreturn for function or ...
>>>>>>  {
>>>>>>  if ( psci_ver > PSCI_VERSION(0, 1) )
>>>>>> diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
>>>>>> index 7619544d14..47e0f59024 100644
>>>>>> --- a/xen/arch/x86/shutdown.c
>>>>>> +++ b/xen/arch/x86/shutdown.c
>>>>>> @@ -118,6 +118,7 @@ static inline void kb_wait(void)
>>>>>>  break;
>>>>>>  }
>>>>>>  +/* SAF-2-safe */
>>>>>>  static void noreturn cf_check __machine_halt(void *unused)
>>>>>>  {
>>>>>>  local_irq_disable();
>>>>>> diff --git a/xen/include/xen/bug.h b/xen/include/xen/bug.h
>>>>>> index e8a4eea71a..d47c54f034 100644
>>>>>> --- a/xen/include/xen/bug.h
>>>>>> +++ b/xen/include/xen/bug.h
>>>>>> @@ -117,6 +117,7 @@ struct bug_frame {
>>>>>>  #endif
>>>>>>#ifndef BUG
>>>>>> +/* SAF-2-safe */
>>>>>>  #define BUG() do {  \
>>>>>>  BUG_FRAME(BUGFRAME_bug,  __LINE__, __FILE__, 0, NULL);  \
>>>>>>  unreachable();  \
>>>>> ... unreachable for macros. But the /* SAF-2-safe */ feels a little bit
>>>>> redundant when a function is marked as 'noreturn'.
>>>>> Is there any way to teach eclair about noreturn?
>>>> Actually I had the same thought while writing this patch. If we can
>>>> adopt unreachable and noreturn consistently maybe we don't need
>>>> SAF-2-safe. If the checker can support it.
>>>> Nicola, what do you think?
>>> 
>>> A couple of remarks:
>>> - if you put the noreturn attribute on some functions, then surely the code 
>>> after those is
>>> reported as unreachable. ECLAIR should pick up all forms of noreturn 
>>> automatically; otherwise, a simple configuration can be used.
>>> 
>>> - Note that the cause of unreachability in the vast majority of cases is 
>>> the call to
>>> __builtin_unreachable(), therefore a textual deviation on the definition of 
>>> unreachable, plus
>>> a bit of ECLAIR configuration, can deviate it (to be clear, just the SAF 
>>> comment is not
>>> sufficient, since deviations comments are meant to be applied at the top 
>>> expansion location,
>>> which is not on the macro definition).
>>> This is what it should look like, roughly:
>>> 
>>> -config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(text(^$, 
>>> -1)))"}
>>> 
>>> #if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
>>> /* SAF-2-safe */
>>> #define unreachable() do {} while (1)
>>> #else
>>> /* SAF-2-safe */
>>> #define unreachable() __builtin_unreachable()
>>> #endif
>>> 
>>> where REGEX will match the translation of SAF-2-safe.
>>> 
>>> However, this will then entail that *some* SAF comments are treated 
>>> specially and, moreover,
>>> that some modification to the definition of unreachable won't work
>>> (e.g.
>>> #define M() __builtin_unreachable()
>>> /* SAF-2-safe */
>>> #define unreachable() M()
>>> 
>>> My opinion is that it's far easier for this to be an eclair configuration 
>>> (which has the
>>> advantage not to depend on the exact definition of unreachable) and then 
>>> perhaps a comment
>>> above it explaining the situation.
>> 
>> I agree here and it is easier to make an overall exception where we list the 
>> cases
>> where this is acceptable (ie all flavors of unreacheable) and document that 
>> eclair
>> was configured using "" to handle this.
> 
> In that case it looks like we all agree that we can go ahead with this
> patch with just the changes to docs/misra/rules.rst to add rule 2.1 and
> remove everything else. Which is v2 of this patch:
> https://marc.info/?l=xen-devel=169283027729298
> 
> Henry, can I get one more release-ack for v2 of this patch (only changes
> to docs/misra, no code changes)?
> 
> Also Bertrand can you provide a formal Ack for v2?
> 

Done, you just need to handle the comment from Julien for it.

Cheers
Bertrand

> 
> I do think we should have a document to track this kind of deviations
> that are not managed by safe.json or exclude-list.json. But I think for
> now the rules.rst notes and the ECLAIR config file (which is under
> xen.git) will suffice.

Re: [PATCH v2] docs/misra: add rule 2.1 exceptions

[Bertrand Marquis]

Hi Stefano,

> On 24 Aug 2023, at 00:39, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> During the discussions that led to the acceptance of Rule 2.1, we
> decided on a few exceptions that were not properly recorded in
> rules.rst. Add them now.
> 
> Signed-off-by: Stefano Stabellini 
> Acked-by: Jan Beulich 
> ---
> Note that safe.json and the codebase are not yet updated with an
> appropriate tag for BUG, panic and friends.
> 
> v2:
> - fix typo in commit message
> - use "only referenced from assembly"
> - use "Deliberate unreachability caused by"
> - add "See safe.json"
> - add acked-by (although I also added "See safe.json")
> ---
> docs/misra/rules.rst | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index 8f0e4d3f25..4f33ed4ba6 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -106,7 +106,18 @@ maintainers if you want to suggest a change.
>* - `Rule 2.1 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_01_1.c>`_
>  - Required
>  - A project shall not contain unreachable code
> - -
> + - The following are allowed:
> + - Invariantly constant conditions, e.g. if(IS_ENABLED(CONFIG_HVM)) 
> { S; }
> + - Switch with a controlling value statically determined not to
> +   match one or more case statements
> + - Functions that are intended to be referenced only from
> +   assembly code (e.g. 'do_trap_fiq')
> + - Deliberate unreachability caused by certain macros/functions,
> +   e.g. BUG, assert_failed, panic, etc. See safe.json.

As Julien requested, you should remove this.

With that handled:

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> + - asm-offsets.c, as they are not linked deliberately, because
> +   they are used to generate definitions for asm modules
> + - Declarations without initializer are safe, as they are not
> +   executed
> 
>* - `Rule 2.6 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_02_06.c>`_
>  - Advisory
> -- 
> 2.25.1
> 

Re: [PATCH v3] docs/misra: add rule 2.1 exceptions

[Bertrand Marquis]

Hi Jan,

> On 27 Sep 2023, at 10:23, Jan Beulich  wrote:
> 
> On 27.09.2023 10:14, Bertrand Marquis wrote:
>>> On 27 Sep 2023, at 09:53, Nicola Vetrini  wrote:
>>> My opinion is that it's far easier for this to be an eclair configuration 
>>> (which has the
>>> advantage not to depend on the exact definition of unreachable) and then 
>>> perhaps a comment
>>> above it explaining the situation.
>> 
>> I agree here and it is easier to make an overall exception where we list the 
>> cases
>> where this is acceptable (ie all flavors of unreacheable) and document that 
>> eclair
>> was configured using "" to handle this.
> 
> What about cppcheck then, for example?

Good point we should check if cppcheck or coverity can do such things.
@Luca: any idea ?

Cheers
Bertrand

> 
> Jan
> 

Re: [PATCH] docs/misra: add rule 11.9

[Bertrand Marquis]

Hi Stefano,

> On 27 Sep 2023, at 03:05, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> Following up from the MISRA C group discussion, add Rule 11.9 to
> docs/misra/rules.rst.
> 
> Signed-off-by: Stefano Stabellini 

I agree with Jan on dropping the "integer" word here.

With that done:
Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Rule 13.1 also discussed but it is already in docs/misra/rules.rst
> ---
> docs/misra/rules.rst | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index 8e7d17d242..28dc3a4d66 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -373,6 +373,11 @@ maintainers if you want to suggest a change.
>  - A cast shall not remove any const or volatile qualification from the 
> type pointed to by a pointer
>  -
> 
> +   * - `Rule 11.9 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_
> + - Required
> + - The macro NULL shall be the only permitted form of integer null 
> pointer constant
> + -
> +
>* - `Rule 12.5 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_05.c>`_
>  - Mandatory
>  - The sizeof operator shall not have an operand which is a function
> -- 
> 2.25.1
> 

Re: [PATCH v3] docs/misra: add rule 2.1 exceptions

[Bertrand Marquis]

Hi,

> On 27 Sep 2023, at 09:53, Nicola Vetrini  wrote:
> 
>>> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>>> > index 695d2fa1f1..2a8527cacc 100644
>>> > --- a/xen/arch/arm/psci.c
>>> > +++ b/xen/arch/arm/psci.c
>>> > @@ -59,6 +59,7 @@ void call_psci_cpu_off(void)
>>> >   }
>>> >   }
>>> >   +/* SAF-2-safe */
>>> I think any use of SAF-2-safe should be accompanied with an attribute...
>>> >   void call_psci_system_off(void)
>>> ... noreturn for function or ...
>>> >   {
>>> >   if ( psci_ver > PSCI_VERSION(0, 1) )
>>> > diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
>>> > index 7619544d14..47e0f59024 100644
>>> > --- a/xen/arch/x86/shutdown.c
>>> > +++ b/xen/arch/x86/shutdown.c
>>> > @@ -118,6 +118,7 @@ static inline void kb_wait(void)
>>> >   break;
>>> >   }
>>> >   +/* SAF-2-safe */
>>> >   static void noreturn cf_check __machine_halt(void *unused)
>>> >   {
>>> >   local_irq_disable();
>>> > diff --git a/xen/include/xen/bug.h b/xen/include/xen/bug.h
>>> > index e8a4eea71a..d47c54f034 100644
>>> > --- a/xen/include/xen/bug.h
>>> > +++ b/xen/include/xen/bug.h
>>> > @@ -117,6 +117,7 @@ struct bug_frame {
>>> >   #endif
>>> > #ifndef BUG
>>> > +/* SAF-2-safe */
>>> >   #define BUG() do {  \
>>> >   BUG_FRAME(BUGFRAME_bug,  __LINE__, __FILE__, 0, NULL);  \
>>> >   unreachable();  \
>>> ... unreachable for macros. But the /* SAF-2-safe */ feels a little bit
>>> redundant when a function is marked as 'noreturn'.
>>> Is there any way to teach eclair about noreturn?
>> Actually I had the same thought while writing this patch. If we can
>> adopt unreachable and noreturn consistently maybe we don't need
>> SAF-2-safe. If the checker can support it.
>> Nicola, what do you think?
> 
> A couple of remarks:
> - if you put the noreturn attribute on some functions, then surely the code 
> after those is
> reported as unreachable. ECLAIR should pick up all forms of noreturn 
> automatically; otherwise, a simple configuration can be used.
> 
> - Note that the cause of unreachability in the vast majority of cases is the 
> call to
> __builtin_unreachable(), therefore a textual deviation on the definition of 
> unreachable, plus
> a bit of ECLAIR configuration, can deviate it (to be clear, just the SAF 
> comment is not
> sufficient, since deviations comments are meant to be applied at the top 
> expansion location,
> which is not on the macro definition).
> This is what it should look like, roughly:
> 
> -config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(text(^$, 
> -1)))"}
> 
> #if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
> /* SAF-2-safe */
> #define unreachable() do {} while (1)
> #else
> /* SAF-2-safe */
> #define unreachable() __builtin_unreachable()
> #endif
> 
> where REGEX will match the translation of SAF-2-safe.
> 
> However, this will then entail that *some* SAF comments are treated specially 
> and, moreover,
> that some modification to the definition of unreachable won't work
> (e.g.
> #define M() __builtin_unreachable()
> /* SAF-2-safe */
> #define unreachable() M()
> 
> My opinion is that it's far easier for this to be an eclair configuration 
> (which has the
> advantage not to depend on the exact definition of unreachable) and then 
> perhaps a comment
> above it explaining the situation.

I agree here and it is easier to make an overall exception where we list the 
cases
where this is acceptable (ie all flavors of unreacheable) and document that 
eclair
was configured using "" to handle this.

Cheers
Bertrand

> 
> -- 
> Nicola Vetrini, BSc
> Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [PATCH v3] docs/misra: add 14.3

[Bertrand Marquis]

Hi Stefano,

> On 8 Sep 2023, at 22:27, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> Add 14.3, with project-wide deviations.
> 
> Also take the opportunity to clarify that parameters of function pointer
> types are expected to have names (Rule 8.2).
> 
> Signed-off-by: Stefano Stabellini 

I am still not quite sure if we should accept a rule if we are deviating
on so much cases but as we can revisit anyway:

Acked-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> Changes in v3:
> - add ,
> - add switch(sizeof(...)) and switch(offsetof(...))
> ---
> docs/misra/rules.rst | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index 34916e266a..ac76e20a9c 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -234,7 +234,8 @@ maintainers if you want to suggest a change.
>* - `Rule 8.2 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_02.c>`_
>  - Required
>  - Function types shall be in prototype form with named parameters
> - -
> + - Clarification: both function and function pointers types shall
> +   have named parameters.
> 
>* - `Rule 8.3 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_03.c>`_
>  - Required
> @@ -385,6 +386,18 @@ maintainers if you want to suggest a change.
>  - A loop counter shall not have essentially floating type
>  -
> 
> +   * - `Rule 14.3 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_
> + - Required
> + - Controlling expressions shall not be invariant
> + - Due to the extensive usage of IS_ENABLED, sizeof compile-time
> +   checks, and other constructs that are detected as errors by MISRA
> +   C scanners, managing the configuration of a MISRA C scanner for
> +   this rule would be unmanageable. Thus, this rule is adopted with
> +   a project-wide deviation on if, ?:, switch(sizeof(...)), and
> +   switch(offsetof(...)) statements.
> +
> +   while(0) and while(1) and alike are allowed.
> +
>* - `Rule 16.7 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_07.c>`_
>  - Required
>  - A switch-expression shall not have essentially Boolean type
> -- 
> 2.25.1
> 

Re: [PATCH v4 1/2] xen: asm-generic support

[Bertrand Marquis]

Hi Oleksii,

> On 6 Sep 2023, at 13:37, Oleksii  wrote:
> 
> Hello Bertrand
> 
> On Mon, 2023-09-04 at 13:39 +, Bertrand Marquis wrote:
>>> diff --git a/xen/scripts/Makefile.asm-generic
>>> b/xen/scripts/Makefile.asm-generic
>>> new file mode 100644
>>> index 00..0aac3f50b8
>>> --- /dev/null
>>> +++ b/xen/scripts/Makefile.asm-generic
>>> @@ -0,0 +1,23 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +# include/asm-generic contains a lot of files that are used
>>> +# verbatim by several architectures.
>>> +#
>>> +# This Makefile reads the file arch/$(SRCARCH)/include/asm/Kbuild
>>> +# and for each file listed in this file with generic-y creates
>>> +# a small wrapper file in $(obj)
>>> (arch/$(SRCARCH)/include/generated/asm)
>>> +
>>> +kbuild-file := $(srctree)/arch/$(SRCARCH)/include/asm/Kbuild
>>> +include $(kbuild-file)
>>> +
>>> +include scripts/Kbuild.include
>>> +
>>> +# Create output directory if not already present
>>> +_dummy := $(shell [ -d $(obj) ] || mkdir -p $(obj))
>>> +
>>> +quiet_cmd_wrap = WRAP$@
>>> +cmd_wrap = echo "\#include " >$@
>>> +
>>> +all: $(patsubst %, $(obj)/%, $(generic-y))
>>> +
>>> +$(obj)/%.h:
>>> + $(call cmd,wrap)
>> 
>> In fact i think your files are not generated in the srctree so this
>> will break if you use out of tree compilation.
> I checked that and in both cases it generated in correct place.
> 
> First case:
> $ CONTAINER_NO_PULL=1 CONTAINER=riscv64
> ./automation/scripts/containerize make XEN_TARGET_ARCH=riscv64 -C xen
> build
> 
> $ ls -la xen/arch/riscv/include/generated/asm/vm_event.h 
> -rw-r--r--. 1 ok ok 34 вер  6 14:32
> xen/arch/riscv/include/generated/asm/vm_event.h
> 
> Second case: ( out-of-tree )
> $ CONTAINER_NO_PULL=1 CONTAINER=riscv64
> ./automation/scripts/containerize make O=xen_build
> XEN_TARGET_ARCH=riscv64 -C xen build V=1
> 
> $ ls -la xen/xen_build/arch/riscv/include/generated/asm/vm_event.h 
> -rw-r--r--. 1 ok ok 34 вер  6 14:34
> xen/xen_build/arch/riscv/include/generated/asm/vm_event.h
> 
> Could you please clarify if there's somithing I might have overlooked?

No I do not think you did.

So obj is empty I would guess.
Anyway you just need to make sure that CFLAGS is coherent with what you 
generate.
So if you generate in $(obj) you need to make sure you use the same in CFLAGS i 
would say.

@anthony: any advice here ?

Cheers
Bertrand



> 
> ~ Oleksii
> 
> 
> 

Re: [PATCH v4 1/2] xen: asm-generic support

[Bertrand Marquis]

Hi Oleksii,

> On 5 Sep 2023, at 15:37, Oleksii  wrote:
> 
> Hi Bertrand,
> 
> On Mon, 2023-09-04 at 13:39 +, Bertrand Marquis wrote:
>> Hi Oleksii,
>> 
>>> On 1 Sep 2023, at 18:02, Oleksii Kurochko
>>>  wrote:
>>> 
>>> Some headers are shared between individual architectures or are
>>> empty.
>>> To avoid duplication of these headers, asm-generic is introduced.
>>> 
>>> With the following patch, an architecture uses generic headers
>>> mentioned in the file arch/$(ARCH)/include/asm/Kbuild.
>> 
>> Kbuild refers to "Kernel build" I guess.
>> I am ok to keep that name to keep things simpler when compared to
>> Linux scripts but it would be good to mention that in the commit
>> message for future reference.
> Sure. I'll add that Kbuild refers to "Kernel build"
>> 
>>> 
>>> To use a generic header is needed to add to
>>> arch/$(ARCH)/include/asm/Kbuild :
>>>generic-y += 
>>> 
>>> For each mentioned header in arch/$(ARCH)/include/asm/Kbuild,
>>> kbuild will generate the necessary wrapper in
>>> arch/$(ARCH)/include/generated/asm.
>>> 
>>> Signed-off-by: Oleksii Kurochko 
>>> ---
>>> Changes in V4:
>>> - introduce asm-generic support
>>> - update commit message
>>> ---
>>> Changes in V3:
>>> - Rename stubs dir to asm-generic
>>> ---
>>> Changes in V2:
>>> - Nothing changed.
>>> ---
>>> xen/Makefile  | 10 +-
>>> xen/arch/arm/include/asm/Kbuild   |  1 +
>>> xen/arch/ppc/include/asm/Kbuild   |  1 +
>>> xen/arch/riscv/include/asm/Kbuild |  1 +
>>> xen/arch/x86/include/asm/Kbuild   |  1 +
>>> xen/scripts/Makefile.asm-generic  | 23 +++
>>> 6 files changed, 36 insertions(+), 1 deletion(-)
>>> create mode 100644 xen/arch/arm/include/asm/Kbuild
>>> create mode 100644 xen/arch/ppc/include/asm/Kbuild
>>> create mode 100644 xen/arch/riscv/include/asm/Kbuild
>>> create mode 100644 xen/arch/x86/include/asm/Kbuild
>>> create mode 100644 xen/scripts/Makefile.asm-generic
>>> 
>>> diff --git a/xen/Makefile b/xen/Makefile
>>> index f57e5a596c..698d6ddeb8 100644
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -438,6 +438,7 @@ ifdef building_out_of_srctree
>>> endif
>>> CFLAGS += -I$(srctree)/include
>>> CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include
>>> +CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include/generated
>> 
>> Why are we generating files in the source tree ? 
>> Shouldn't we keep it unmodified ?
> I think you are right.
> I got myself confused because I do not use out-of-tree compilation so
> for me it looked like $(srctree).
> 
> It would be better to use $(objtree) instead.

Ack

>> 
>>> 
>>> # Note that link order matters!
>>> ALL_OBJS-y:= common/built_in.o
>>> @@ -580,6 +581,7 @@ _clean:
>>> rm -f $(TARGET).efi $(TARGET).efi.map $(TARGET).efi.elf
>>> $(TARGET).efi.stripped
>>> rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
>>> rm -f .banner .allconfig.tmp include/xen/compile.h
>>> + rm -rf arch/*/include/generated
>>> 
>> 
>> You must use the same as for CFLAGS here so $(srctree) would be
>> needed.
>> (or something else depending on the fix for previous comment)
> Thanks. I'll change to the value mentioned in CFLAGS.
> 
>> 
>>> .PHONY: _distclean
>>> _distclean: clean
>>> @@ -589,7 +591,7 @@ $(TARGET).gz: $(TARGET)
>>> gzip -n -f -9 < $< > $@.new
>>> mv $@.new $@
>>> 
>>> -$(TARGET): outputmakefile FORCE
>>> +$(TARGET): outputmakefile asm-generic FORCE
>>> $(Q)$(MAKE) $(build)=tools
>>> $(Q)$(MAKE) $(build)=. include/xen/compile.h
>>> $(Q)$(MAKE) $(build)=include all
>>> @@ -667,6 +669,12 @@ endif # need-sub-make
>>> PHONY += FORCE
>>> FORCE:
>>> 
>>> +# Support for using generic headers in asm-generic
>>> +PHONY += asm-generic
>>> +asm-generic:
>>> + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic \
>>> +obj=arch/$(SRCARCH)/include/generated/asm
>>> +
>>> # Declare the contents of the PHONY variable as phony.  We keep
>>> that
>>> # information in a variable so we can use it in if_changed and
>>> friends.
>>> .PHONY: $(PHONY)
>>> diff --git a/xen/arch/arm/includ

Re: xen | Failed pipeline for staging-4.17 | 699de512

[Bertrand Marquis]

Hi Jan,

> On 5 Sep 2023, at 10:36, Jan Beulich  wrote:
> 
> On 05.09.2023 10:23, GitLab wrote:
>> 
>> 
>> Pipeline #992747061 has failed!
>> 
>> Project: xen ( https://gitlab.com/xen-project/xen )
>> Branch: staging-4.17 ( 
>> https://gitlab.com/xen-project/xen/-/commits/staging-4.17 )
>> 
>> Commit: 699de512 ( 
>> https://gitlab.com/xen-project/xen/-/commit/699de512748d8e3bdcb3225b3b2a77c10cfd2408
>>  )
>> Commit Message: x86/irq: fix reporting of spurious i8259 interr...
>> Commit Author: Roger Pau Monné
>> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>> 
>> 
>> Pipeline #992747061 ( 
>> https://gitlab.com/xen-project/xen/-/pipelines/992747061 ) triggered by 
>> Ganis ( https://gitlab.com/ganis )
>> had 5 failed jobs.
>> 
>> Job #5017577664 ( https://gitlab.com/xen-project/xen/-/jobs/5017577664/raw )
>> 
>> Stage: test
>> Name: qemu-smoke-arm64-gcc-staticmem
>> Job #5017577671 ( https://gitlab.com/xen-project/xen/-/jobs/5017577671/raw )
>> 
>> Stage: test
>> Name: qemu-smoke-arm64-gcc-boot-cpupools
>> Job #5017577635 ( https://gitlab.com/xen-project/xen/-/jobs/5017577635/raw )
>> 
>> Stage: test
>> Name: qemu-alpine-arm64-gcc
>> Job #5017577678 ( https://gitlab.com/xen-project/xen/-/jobs/5017577678/raw )
>> 
>> Stage: test
>> Name: qemu-smoke-arm32-gcc
>> Job #5017577654 ( https://gitlab.com/xen-project/xen/-/jobs/5017577654/raw )
>> 
>> Stage: test
>> Name: qemu-smoke-arm64-gcc
>> 
> 
> Hmm, none of what I pushed looks to stand a fair chance of affecting Arm.
> IOW I'm afraid I don't see what's going on here.

curl -fsSLO https://github.com/qemu/qemu/raw/v5.2.0/pc-bios/efi-virtio.rom
curl: (22) The requested URL returned error: 503

It seems that we depend on some bios images in github and downloading those
did not work.

I just checked and they are there so might have been a transient issue.
I would suggest to retrigger and check.

Cheers
Bertrand

> 
> Jan
> 

Re: [PATCH] Arm: constrain {,u}int64_aligned_t in public header

[Bertrand Marquis]

Hi Jan,

> On 4 Sep 2023, at 17:20, Jan Beulich  wrote:
> 
> On 04.09.2023 16:05, Bertrand Marquis wrote:
>>> On 4 Sep 2023, at 16:01, Jan Beulich  wrote:
>>> 
>>> On 04.09.2023 15:42, Bertrand Marquis wrote:
>>>>> On 1 Sep 2023, at 09:26, Jan Beulich  wrote:
>>>>> 
>>>>> This using a GNU extension, it may not be exposed in general, just like
>>>> 
>>>> Nit: Missing "is"
>>> 
>>> I would guess you would want it added as the 2nd word of the sentence. If
>>> not, please clarify where you think it is missing. If so, then I'm afraid
>>> I can't parse the sentence anymore with it added (i.e. there would need
>>> to be further modifications, e.g. at the very least "so" after the first
>>> comma).
>> 
>> Sorry yes, it should be "This is using a GNU".
> 
> So as I inferred, yet as said - according to my reading the sentence then
> ends up broken. If you continue to think the sentence is wrong as is, would
> it help if I replaced "This" by "For"?

The sentence looks a bit weird to me but I am not a native english speaker.
Any reformulation coming from me will probably not be good english anyway.
I understand that one as "we don't want to expose this in general because
it is a using a GNU extension and x86 is already not", the sentence here is
just asking me a bit more thinking that is it.

As this was a Nit, feel free to ignore and you can keep my R-b.

Cheers
Bertrand

> 
> Jan
> 
>>>>> is done on x86. External consumers need to make this type available up
>>>>> front (just like we expect {,u}int_t to be supplied) - unlike on x86
>>>>> the type is actually needed outside of tools-only interfaces, because
>>>>> guest handle definitions use it.
>>>>> 
>>>>> While there also add underscores around "aligned".
>>>>> 
>>>>> Signed-off-by: Jan Beulich 
>>>> 
>>>> With the Nit fixed (can be done on commit):
>>>> 
>>>> Reviewed-by: Bertrand Marquis 
>>> 
>>> Thanks, but I'm afraid I can't take it before the above is clarified.
>> 
>> Please see above.
>> 
>> Bertrand
>> 
>>> 
>>> Jan

Re: [PATCH] xen/arm: ffa: fix guest map RX/TX error code

[Bertrand Marquis]

Hi Jens,

> On 4 Sep 2023, at 16:58, Jens Wiklander  wrote:
> 
> FFA_RXTX_MAP is currently limited to mapping only one 4k page for each
> RX and TX buffer. If a guest tries to map more than one page, an error
> is returned. Until this patch, we have been using FFA_RET_NOT_SUPPORTED.
> However, that error code is reserved in the FF-A specification to report
> that the function is not implemented. Of all the other defined error
> codes, the least bad is FFA_RET_INVALID_PARAMETERS, so use that instead.

Agree and thanks for the fix.

> 
> Fixes: 38d81e7ccb11 ("xen/arm: ffa: support mapping guest RX/TX buffers")
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/arch/arm/tee/ffa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 802b2dbb1d36..183528d13388 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -706,7 +706,7 @@ static uint32_t handle_rxtx_map(uint32_t fid, register_t 
> tx_addr,
> {
> printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (limit 
> %u)\n",
>page_count, FFA_MAX_RXTX_PAGE_COUNT);
> -return FFA_RET_NOT_SUPPORTED;
> +return FFA_RET_INVALID_PARAMETERS;
> }
> 
> /* Already mapped */
> -- 
> 2.34.1
> 

Re: [PATCH] Arm: constrain {,u}int64_aligned_t in public header

[Bertrand Marquis]

Hi Jan,

> On 4 Sep 2023, at 16:01, Jan Beulich  wrote:
> 
> On 04.09.2023 15:42, Bertrand Marquis wrote:
>>> On 1 Sep 2023, at 09:26, Jan Beulich  wrote:
>>> 
>>> This using a GNU extension, it may not be exposed in general, just like
>> 
>> Nit: Missing "is"
> 
> I would guess you would want it added as the 2nd word of the sentence. If
> not, please clarify where you think it is missing. If so, then I'm afraid
> I can't parse the sentence anymore with it added (i.e. there would need
> to be further modifications, e.g. at the very least "so" after the first
> comma).

Sorry yes, it should be "This is using a GNU".

> 
>>> is done on x86. External consumers need to make this type available up
>>> front (just like we expect {,u}int_t to be supplied) - unlike on x86
>>> the type is actually needed outside of tools-only interfaces, because
>>> guest handle definitions use it.
>>> 
>>> While there also add underscores around "aligned".
>>> 
>>> Signed-off-by: Jan Beulich 
>> 
>> With the Nit fixed (can be done on commit):
>> 
>> Reviewed-by: Bertrand Marquis 
> 
> Thanks, but I'm afraid I can't take it before the above is clarified.

Please see above.

Bertrand

> 
> Jan

Re: [PATCH v1 1/2] xen/arm: Add macro XEN_VM_MAPPING

[Bertrand Marquis]

Hi Leo,

> On 31 Aug 2023, at 13:01, Leo Yan  wrote:
> 
> Xen maps the virtual memory space starting from L0 slot 4, so it's open
> coded for macros with the offset '4'.
> 
> For more readable, add a new macro XEN_VM_MAPPING which defines the
> start slot for Xen virtual memory mapping, and all virtual memory
> regions are defined based on it.
> 
> Signed-off-by: Leo Yan 

As said on patch 2, please check current staging code as it does not work
like this anymore.

Cheers
Bertrand

> ---
> xen/arch/arm/include/asm/config.h | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/config.h 
> b/xen/arch/arm/include/asm/config.h
> index 83cbf6b0cb..21f4e68a40 100644
> --- a/xen/arch/arm/include/asm/config.h
> +++ b/xen/arch/arm/include/asm/config.h
> @@ -117,11 +117,14 @@
> #define XEN_VIRT_START  _AT(vaddr_t, MB(2))
> #else
> 
> +#define IDENTITY_MAPPING_AREA_NR_L0 4
> +#define XEN_VM_MAPPING SLOT0(IDENTITY_MAPPING_AREA_NR_L0)
> +
> #define SLOT0_ENTRY_BITS  39
> #define SLOT0(slot) (_AT(vaddr_t,slot) << SLOT0_ENTRY_BITS)
> #define SLOT0_ENTRY_SIZE  SLOT0(1)
> 
> -#define XEN_VIRT_START  (SLOT0(4) + _AT(vaddr_t, MB(2)))
> +#define XEN_VIRT_START  (XEN_VM_MAPPING + _AT(vaddr_t, MB(2)))
> #endif
> 
> /*
> @@ -184,12 +187,10 @@
> 
> #else /* ARM_64 */
> 
> -#define IDENTITY_MAPPING_AREA_NR_L0  4
> -
> -#define VMAP_VIRT_START  (SLOT0(4) + GB(1))
> +#define VMAP_VIRT_START  (XEN_VM_MAPPING + GB(1))
> #define VMAP_VIRT_SIZE   GB(1)
> 
> -#define FRAMETABLE_VIRT_START  (SLOT0(4) + GB(32))
> +#define FRAMETABLE_VIRT_START  (XEN_VM_MAPPING + GB(32))
> #define FRAMETABLE_SIZEGB(32)
> #define FRAMETABLE_NR  (FRAMETABLE_SIZE / sizeof(*frame_table))
> 
> -- 
> 2.39.2
> 

Re: [PATCH v1 2/2] xen/arm: Enlarge identity map space to 127TiB

[Bertrand Marquis]

Hi Leo,

> On 31 Aug 2023, at 13:01, Leo Yan  wrote:
> 
> On some platforms, the memory regions could be:
> 
>  (XEN) MODULE[0]: 0807f6df - 0807f6f3e000 Xen
>  (XEN) MODULE[1]: 0807f8054000 - 0807f8056000 Device Tree
>  (XEN) MODULE[2]: fa834000 - fc5de1d5 Ramdisk
>  (XEN) MODULE[3]: fc5df000 - ffb3f810 Kernel
> 
> In this case, the Xen binary is loaded above 2TB, so Xen fails to boot
> up due to the out of the identity map space.
> 
> This patch enlarges identity map space to 127TiB, which can support the
> memory space [0x0 .. 0x7eff__], thus it has flexibility for
> support different platforms.
> 
> Fixes: 1c78d76b67 ("xen/arm64: mm: Introduce helpers to 
> prepare/enable/disable")
> Reported-by: Alexey Klimov 
> Signed-off-by: Leo Yan 

This is not based on the current status of staging where this part of the
code was modified.

Currently Xen virtual address is at 2TB and the extension you are making
will potentially make it possible to load Xen at 2TB which will clash for the
identity mapping handling in Xen.

Please rebase on the latest staging and check there how you can do as
this patch if rebased on staging right now with rightfully end in a compilation
error.

Cheers
Bertrand

> ---
> xen/arch/arm/include/asm/config.h | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/config.h 
> b/xen/arch/arm/include/asm/config.h
> index 21f4e68a40..3e97c95b57 100644
> --- a/xen/arch/arm/include/asm/config.h
> +++ b/xen/arch/arm/include/asm/config.h
> @@ -87,11 +87,11 @@
>  *   2G -   4G   Domheap: on-demand-mapped
>  *
>  * ARM64 layout:
> - * 0x - 0x01ff (2TB, L0 slots [0..3])
> + * 0x - 0x7eff (127TB, L0 slots [0..253])
>  *
>  *  Reserved to identity map Xen
>  *
> - * 0x0200 - 0x027f (512GB, L0 slot [4])
> + * 0x07f0 - 0x7fff (1TB, L0 slot [254..255])
>  *  (Relative offsets)
>  *   0  -   2M   Unmapped
>  *   2M -  10M   Xen text, data, bss
> @@ -103,9 +103,6 @@
>  *
>  *  32G -  64G   Frametable: 56 bytes per page for 2TB of RAM
>  *
> - * 0x0280 - 0x7fff (125TB, L0 slots [5..255])
> - *  Unused
> - *
>  * 0x8000 - 0x84ff (5TB, L0 slots [256..265])
>  *  1:1 mapping of RAM
>  *
> @@ -117,7 +114,7 @@
> #define XEN_VIRT_START  _AT(vaddr_t, MB(2))
> #else
> 
> -#define IDENTITY_MAPPING_AREA_NR_L0 4
> +#define IDENTITY_MAPPING_AREA_NR_L0 254
> #define XEN_VM_MAPPING SLOT0(IDENTITY_MAPPING_AREA_NR_L0)
> 
> #define SLOT0_ENTRY_BITS  39
> -- 
> 2.39.2
> 

Re: [PATCH] Arm: constrain {,u}int64_aligned_t in public header

[Bertrand Marquis]

Hi Jan,

> On 1 Sep 2023, at 09:26, Jan Beulich  wrote:
> 
> This using a GNU extension, it may not be exposed in general, just like

Nit: Missing "is"

> is done on x86. External consumers need to make this type available up
> front (just like we expect {,u}int_t to be supplied) - unlike on x86
> the type is actually needed outside of tools-only interfaces, because
> guest handle definitions use it.
> 
> While there also add underscores around "aligned".
> 
> Signed-off-by: Jan Beulich 

With the Nit fixed (can be done on commit):

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> 
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -152,8 +152,10 @@
> 
> #define XEN_HYPERCALL_TAG   0XEA1
> 
> -#define  int64_aligned_t  int64_t __attribute__((aligned(8)))
> -#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
> +#if defined(__XEN__) || defined(__XEN_TOOLS__)
> +#define  int64_aligned_t  int64_t __attribute__((__aligned__(8)))
> +#define uint64_aligned_t uint64_t __attribute__((__aligned__(8)))
> +#endif
> 
> #ifndef __ASSEMBLY__
> #define ___DEFINE_XEN_GUEST_HANDLE(name, type)  \

Re: [PATCH v4 1/2] xen: asm-generic support

[Bertrand Marquis]

Hi Oleksii,

> On 1 Sep 2023, at 18:02, Oleksii Kurochko  wrote:
> 
> Some headers are shared between individual architectures or are empty.
> To avoid duplication of these headers, asm-generic is introduced.
> 
> With the following patch, an architecture uses generic headers
> mentioned in the file arch/$(ARCH)/include/asm/Kbuild.

Kbuild refers to "Kernel build" I guess.
I am ok to keep that name to keep things simpler when compared to
Linux scripts but it would be good to mention that in the commit
message for future reference. 

> 
> To use a generic header is needed to add to
> arch/$(ARCH)/include/asm/Kbuild :
>generic-y += 
> 
> For each mentioned header in arch/$(ARCH)/include/asm/Kbuild,
> kbuild will generate the necessary wrapper in
> arch/$(ARCH)/include/generated/asm.
> 
> Signed-off-by: Oleksii Kurochko 
> ---
> Changes in V4:
> - introduce asm-generic support
> - update commit message
> ---
> Changes in V3:
> - Rename stubs dir to asm-generic
> ---
> Changes in V2:
> - Nothing changed.
> ---
> xen/Makefile  | 10 +-
> xen/arch/arm/include/asm/Kbuild   |  1 +
> xen/arch/ppc/include/asm/Kbuild   |  1 +
> xen/arch/riscv/include/asm/Kbuild |  1 +
> xen/arch/x86/include/asm/Kbuild   |  1 +
> xen/scripts/Makefile.asm-generic  | 23 +++
> 6 files changed, 36 insertions(+), 1 deletion(-)
> create mode 100644 xen/arch/arm/include/asm/Kbuild
> create mode 100644 xen/arch/ppc/include/asm/Kbuild
> create mode 100644 xen/arch/riscv/include/asm/Kbuild
> create mode 100644 xen/arch/x86/include/asm/Kbuild
> create mode 100644 xen/scripts/Makefile.asm-generic
> 
> diff --git a/xen/Makefile b/xen/Makefile
> index f57e5a596c..698d6ddeb8 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -438,6 +438,7 @@ ifdef building_out_of_srctree
> endif
> CFLAGS += -I$(srctree)/include
> CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include
> +CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include/generated

Why are we generating files in the source tree ? 
Shouldn't we keep it unmodified ?

> 
> # Note that link order matters!
> ALL_OBJS-y:= common/built_in.o
> @@ -580,6 +581,7 @@ _clean:
> rm -f $(TARGET).efi $(TARGET).efi.map $(TARGET).efi.elf $(TARGET).efi.stripped
> rm -f asm-offsets.s arch/*/include/asm/asm-offsets.h
> rm -f .banner .allconfig.tmp include/xen/compile.h
> + rm -rf arch/*/include/generated
> 

You must use the same as for CFLAGS here so $(srctree) would be needed.
(or something else depending on the fix for previous comment)

> .PHONY: _distclean
> _distclean: clean
> @@ -589,7 +591,7 @@ $(TARGET).gz: $(TARGET)
> gzip -n -f -9 < $< > $@.new
> mv $@.new $@
> 
> -$(TARGET): outputmakefile FORCE
> +$(TARGET): outputmakefile asm-generic FORCE
> $(Q)$(MAKE) $(build)=tools
> $(Q)$(MAKE) $(build)=. include/xen/compile.h
> $(Q)$(MAKE) $(build)=include all
> @@ -667,6 +669,12 @@ endif # need-sub-make
> PHONY += FORCE
> FORCE:
> 
> +# Support for using generic headers in asm-generic
> +PHONY += asm-generic
> +asm-generic:
> + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic \
> +obj=arch/$(SRCARCH)/include/generated/asm
> +
> # Declare the contents of the PHONY variable as phony.  We keep that
> # information in a variable so we can use it in if_changed and friends.
> .PHONY: $(PHONY)
> diff --git a/xen/arch/arm/include/asm/Kbuild b/xen/arch/arm/include/asm/Kbuild
> new file mode 100644
> index 00..a4e40e534e
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/xen/arch/ppc/include/asm/Kbuild b/xen/arch/ppc/include/asm/Kbuild
> new file mode 100644
> index 00..a4e40e534e
> --- /dev/null
> +++ b/xen/arch/ppc/include/asm/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/xen/arch/riscv/include/asm/Kbuild 
> b/xen/arch/riscv/include/asm/Kbuild
> new file mode 100644
> index 00..a4e40e534e
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/xen/arch/x86/include/asm/Kbuild b/xen/arch/x86/include/asm/Kbuild
> new file mode 100644
> index 00..a4e40e534e
> --- /dev/null
> +++ b/xen/arch/x86/include/asm/Kbuild
> @@ -0,0 +1 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> diff --git a/xen/scripts/Makefile.asm-generic 
> b/xen/scripts/Makefile.asm-generic
> new file mode 100644
> index 00..0aac3f50b8
> --- /dev/null
> +++ b/xen/scripts/Makefile.asm-generic
> @@ -0,0 +1,23 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# include/asm-generic contains a lot of files that are used
> +# verbatim by several architectures.
> +#
> +# This Makefile reads the file arch/$(SRCARCH)/include/asm/Kbuild
> +# and for each file listed in this file with generic-y creates
> +# a small wrapper file in $(obj) (arch/$(SRCARCH)/include/generated/asm)
> +
> +kbuild-file := $(srctree)/arch/$(SRCARCH)/include/asm/Kbuild
> +include $(kbuild-file)
> +
> 

Re: [PATCH 1/2] xen/arm: smmuv3: Add missing U for shifted constant

[Bertrand Marquis]

Hi Michal,

> On 4 Sep 2023, at 11:14, Michal Orzel  wrote:
> 
> When running with SMMUv3 and UBSAN enabled, the following is printed:
> 
> (XEN) UBSAN: Undefined behaviour in drivers/passthrough/arm/smmu-v3.c:297:12
> (XEN) left shift of 1 by 31 places cannot be represented in type 'int'
> 
> This refers to shift in Q_OVERFLOW_FLAG that is missing 'U' suffix.
> While there, also fix the same in GBPA_UPDATE.
> 
> This should address MISRA Rule 7.2:
>A "u" or "U" suffix shall be applied to all integer constants that
>are represented in an unsigned type
> 
> Signed-off-by: Michal Orzel 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> xen/drivers/passthrough/arm/smmu-v3.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/arm/smmu-v3.h 
> b/xen/drivers/passthrough/arm/smmu-v3.h
> index b381ad373845..05f6b1fb7e33 100644
> --- a/xen/drivers/passthrough/arm/smmu-v3.h
> +++ b/xen/drivers/passthrough/arm/smmu-v3.h
> @@ -87,7 +87,7 @@
> #define CR2_E2H (1 << 0)
> 
> #define ARM_SMMU_GBPA 0x44
> -#define GBPA_UPDATE (1 << 31)
> +#define GBPA_UPDATE (1U << 31)
> #define GBPA_ABORT (1 << 20)
> 
> #define ARM_SMMU_IRQ_CTRL 0x50
> @@ -159,7 +159,7 @@
> 
> #define Q_IDX(llq, p) ((p) & ((1 << (llq)->max_n_shift) - 1))
> #define Q_WRP(llq, p) ((p) & (1 << (llq)->max_n_shift))
> -#define Q_OVERFLOW_FLAG (1 << 31)
> +#define Q_OVERFLOW_FLAG (1U << 31)
> #define Q_OVF(p) ((p) & Q_OVERFLOW_FLAG)
> #define Q_ENT(q, p) ((q)->base + \
> Q_IDX(&((q)->llq), p) * \
> -- 
> 2.25.1
> 

Re: [PATCH] docs/misra: add 14.3 and 14.4

[Bertrand Marquis]

Hi,

> On 30 Aug 2023, at 09:58, Jan Beulich  wrote:
> 
> On 30.08.2023 09:54, Bertrand Marquis wrote:
>>> On 30 Aug 2023, at 02:59, Stefano Stabellini  wrote:
>>> +   * - `Rule 14.4 
>>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_04.c>`_
>>> + - Required
>>> + - The controlling expression of an if statement and the controlling
>>> +   expression of an iteration-statement shall have essentially
>>> +   Boolean type
>>> + - Implicit conversions of integers, pointers, and chars to boolean
>>> +   are allowed
>> 
>> I am a bit wondering here what is remaining after this deviation.
> 
> Hmm, good point - floating point (and alike) types, which we don't use anyway.

So we accept the rule but we deviate all cases that would apply.
I do not think we should do that.

Bertrand

> 
> Jan
> 

Re: [PATCH v2 1/2] xen: add stubs dir to include path

[Bertrand Marquis]

Hi Jan,

> On 30 Aug 2023, at 09:30, Jan Beulich  wrote:
> 
> On 29.08.2023 16:34, Oleksii Kurochko wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -438,6 +438,7 @@ ifdef building_out_of_srctree
>> endif
>> CFLAGS += -I$(srctree)/include
>> CFLAGS += -I$(srctree)/arch/$(SRCARCH)/include
>> +CFLAGS += -I$(srctree)/include/stubs
>> 
>> # Note that link order matters!
>> ALL_OBJS-y:= common/built_in.o
> 
> I have to admit that I'm not entirely happy with the name. I wonder what
> other REST maintainers think. In particular I would consider using
> Linux'es "asm-generic" name instead, allowing to cover both stub headers
> like the one to be introduced here, but also other kinds of "fallback"
> ones.
> 

This is a great idea.
+1 on asm-generic

Cheers
Bertrand

> Jan
> 

Re: [PATCH] docs/misra: add 14.3 and 14.4

[Bertrand Marquis]

Hi Stefano,

> On 30 Aug 2023, at 02:59, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> Add 14.3, with a project-wide deviations on if statements.
> Add 14.4, clarifying that implicit conversions of integers, chars and
> pointers to bool are allowed.
> 
> Also take the opportunity to clarify that parameters of function pointer
> types are expected to have names (Rule 8.2).
> 
> Signed-off-by: Stefano Stabellini 
> ---
> docs/misra/rules.rst | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index db30632b93..6cde4feeae 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -234,7 +234,7 @@ maintainers if you want to suggest a change.
>* - `Rule 8.2 
> `_
>  - Required
>  - Function types shall be in prototype form with named parameters
> - -
> + - Function pointer types shall have named parameters too.


I would just modify to Function and Function pointers types shall be ...

> 
>* - `Rule 8.3 
> `_
>  - Required
> @@ -332,6 +332,24 @@ maintainers if you want to suggest a change.
>  - A loop counter shall not have essentially floating type
>  -
> 
> +   * - `Rule 14.3 
> `_
> + - Required
> + - Controlling expressions shall not be invariant
> + - Due to the extensive usage of IS_ENABLED, sizeof compile-time
> +   checks, and other constructs that are detected as errors by MISRA
> +   C scanners, managing the configuration of a MISRA C scanner for
> +   this rule would be unmanageable. Thus, this rule is adopted with
> +   a project-wide deviation on 'if' statements. The rule only
> +   applies to while, for, do ... while, ?:, and switch statements.

Didn't we also said that we would accept while(0) and while(1) ?
Also i agree with Jan, ? is really the same as if so we should not treat it 
differently.

> +
> +   * - `Rule 14.4 
> `_
> + - Required
> + - The controlling expression of an if statement and the controlling
> +   expression of an iteration-statement shall have essentially
> +   Boolean type
> + - Implicit conversions of integers, pointers, and chars to boolean
> +   are allowed

I am a bit wondering here what is remaining after this deviation.

> +
>* - `Rule 16.7 
> `_
>  - Required
>  - A switch-expression shall not have essentially Boolean type
> -- 
> 2.25.1
> 

Cheers
Bertrand

Re: [PATCH v2] docs/misra: add rules 10.1 10.2 10.3 10.4

[Bertrand Marquis]

Hi Stefano,

> On 25 Aug 2023, at 23:48, Stefano Stabellini  wrote:
> 
> From: Stefano Stabellini 
> 
> 10.1 with several caveats, described in the notes.
> 10.3 and 10.4 as "aspirational" guidelines, as clarified in the notes.
> 
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v2:
> - typo fix
> - Implicit conversions to boolean for conditionals and logical operators
> - make -C xen
> ---
> docs/misra/rules.rst | 53 
> 1 file changed, 53 insertions(+)
> 
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index db30632b93..34916e266a 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -310,6 +310,59 @@ maintainers if you want to suggest a change.
>  - An element of an object shall not be initialized more than once
>  -
> 
> +   * - `Rule 10.1 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_01.c>`_
> + - Required
> + - Operands shall not be of an inappropriate essential type
> + - The following are allowed:
> + - Value-preserving conversions of integer constants
> + - Bitwise and, or, xor, one's complement, bitwise and assignment,
> +   bitwise or assignment, bitwise xor assignment (bitwise and, or, 
> xor
> +   are safe on non-negative integers; also Xen assumes two's 
> complement
> +   representation)
> + - Left shift, right shift, left shift assignment, right shift
> +   assignment (see C-language-toolchain.rst for uses of
> +   compilers' extensions)
> + - Implicit conversions to boolean for conditionals (?: if while
> +   for) and logical operators (! || &&)
> +
> +   * - `Rule 10.2 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_02.c>`_
> + - Required
> + - Expressions of essentially character type shall not be used
> +   inappropriately in addition and subtraction operations
> + -
> +
> +   * - `Rule 10.3 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_03.c>`_
> + - Required
> + - The value of an expression shall not be assigned to an object
> +   with a narrower essential type or of a different essential type
> +   category
> + - Please beware that this rule has many violations in the Xen
> +   codebase today, and its adoption is aspirational. However, when
> +   submitting new patches please try to decrease the number of
> +   violations when possible.
> +
> +   gcc has a helpful warning that can help you spot and remove
> +   violations of this kind: conversion. For instance, you can use
> +   it as follows:
> +
> +   CFLAGS="-Wconversion -Wno-error=sign-conversion 
> -Wno-error=conversion" make -C xen
> +
> +   * - `Rule 10.4 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_10_04.c>`_
> + - Required
> + - Both operands of an operator in which the usual arithmetic
> +   conversions are performed shall have the same essential type
> +   category
> + - Please beware that this rule has many violations in the Xen
> +   codebase today, and its adoption is aspirational. However, when
> +   submitting new patches please try to decrease the number of
> +   violations when possible.
> +
> +   gcc has a helpful warning that can help you spot and remove
> +   violations of this kind: arith-conversion. For instance, you
> +   can use it as follows:
> +
> +   CFLAGS="-Warith-conversion -Wno-error=arith-conversion" make -C xen
> +
>* - `Rule 12.5 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_05.c>`_
>  - Mandatory
>  - The sizeof operator shall not have an operand which is a function
> -- 
> 2.25.1
> 

Re: Community Manager update - August 2023

[Bertrand Marquis]

Hi Kelly,

> On 18 Aug 2023, at 12:55, Kelly Choi  wrote:
>
> Hi everyone! :)
>
> I hope you're all well.
>
> If we haven't met before, I'd like to introduce myself. I'm Kelly, the 
> Community Manager for The Xen Project. My role is to support everyone and 
> make sure the project is healthy and thriving.
>
> The latest update below requires your attention:
>
> • We will be moving IRC channels fully to Matrix in September 2023. Once 
> the channels have been created, further information will be shared.
> • New Mission Statement, goals, and purpose is attached to this email and 
> will be shared publicly.
> Should anyone have any concerns or feedback, please let me know

In embedded and automotive in particular one keyword that would be interesting 
to have is "Safety".

We could add it in the mission statement and in the embedded technology goals:
- The project aims to enable innovation, scalability, safety and security in 
virtualization solutions.
- Transform embedded and automotive sectors with mature, safe and secure 
solutions.

What do other think ?

Regards
Bertrand


>
> Many thanks,
> Kelly Choi
>
> Open Source Community Manager, XenServer
> Cloud Software Group



New mission statement_.pdf
Description: New mission statement_.pdf

Re: [XEN PATCH v11 14/14] docs: add Arm FF-A mediator

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
> Partition in secure world.
> 
> [1] https://developer.arm.com/documentation/den0077/latest
> Signed-off-by: Jens Wiklander 
> Reviewed-by: Henry Wang 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v10->v11
> - Add a CHANGELOG.md entry as requested
> ---
> CHANGELOG.md |  3 ++-
> SUPPORT.md   |  9 +
> docs/man/xl.cfg.5.pod.in | 15 +++
> 3 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index 7d7e0590f8c6..f24c8c4b8011 100644
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -24,7 +24,8 @@ The format is based on [Keep a 
> Changelog](https://keepachangelog.com/en/1.0.0/)
>  - xl/libxl can customize SMBIOS strings for HVM guests.
>  - Add support for AVX512-FP16 on x86.
>  - On Arm, Xen supports guests running SVE/SVE2 instructions. (Tech Preview)
> -
> + - On Arm, add suport for Firmware Framework for Arm A-profile (FF-A) 
> Mediator
> +   (Tech Preview)
> 
> ## 
> [4.17.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.17.0)
>  - 2022-12-12
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 35a6249e03b2..fe512762cee7 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -840,6 +840,15 @@ that covers the DMA of the device to be passed through.
> 
> No support for QEMU backends in a 16K or 64K domain.
> 
> +### ARM: Firmware Framework for Arm A-profile (FF-A) Mediator
> +
> +Status, Arm64: Tech Preview
> +
> +There are still some code paths where a vCPU may hog a pCPU longer than
> +necessary. The FF-A mediator is not yet implemented for Arm32. Part of the
> +FF-A specification is not supported, see the top comment in
> +xen/arch/arm/tee/ffa.c for limitations.
> +
> ### ARM: Guest Device Tree support
> 
> Status: Supported
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index a2bccd5b48a1..ec4864958e0e 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -1656,6 +1656,21 @@ in OP-TEE.
> 
> This feature is a B.
> 
> +=item B
> +
> +B Allow a guest to communicate via FF-A with Secure Partitions
> +(SP), default false.
> +
> +Currently only a small subset of the FF-A specification is supported. Just
> +enough to communicate with OP-TEE. In general only direct messaging and
> +sharing memory with one SP. More advanced use cases where memory might be
> +shared or donated to multiple SPs are not supported.
> +
> +See L<https://developer.arm.com/documentation/den0077/latest> for more
> +information about FF-A.
> +
> +This feature is a B.
> +
> =back
> 
> =back
> -- 
> 2.34.1
> 

Re: [XEN PATCH v11 12/14] xen/arm: ffa: list current limitations

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> Adds comments with a list of unsupported FF-A interfaces and limitations
> in the implemented FF-A interfaces.
> 
> Signed-off-by: Jens Wiklander 
> Reviewed-by: Henry Wang 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v10->v11
> - No changes
> ---
> xen/arch/arm/tee/ffa.c | 31 +++
> 1 file changed, 31 insertions(+)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index eb4a58fec470..cfbabec81dd2 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -13,6 +13,37 @@
>  *https://developer.arm.com/documentation/den0077/e
>  * TEEC-1.0C: TEE Client API Specification version 1.0c available at
>  *
> https://globalplatform.org/specs-library/tee-client-api-specification/
> + *
> + * Notes on the the current implementation.
> + *
> + * Unsupported FF-A interfaces:
> + * o FFA_MSG_POLL and FFA_MSG_SEND - deprecated in FF-A-1.1-REL0
> + * o FFA_MEM_RETRIEVE_* - Used when sharing memory from an SP to a VM
> + * o FFA_MEM_DONATE_* and FFA_MEM_LEND_* - Used when tranferring ownership
> + *   or access of a memory region
> + * o FFA_MSG_SEND2 and FFA_MSG_WAIT - Used for indirect messaging
> + * o FFA_MSG_YIELD
> + * o FFA_INTERRUPT - Used to report preemption
> + * o FFA_RUN
> + *
> + * Limitations in the implemented FF-A interfaces:
> + * o FFA_RXTX_MAP_*:
> + *   - Maps only one 4k page as RX and TX buffers
> + *   - Doesn't support forwarding this call on behalf of an endpoint
> + * o FFA_MEM_SHARE_*: only supports sharing
> + *   - from a VM to an SP
> + *   - with one borrower
> + *   - with the memory transaction descriptor in the RX/TX buffer
> + *   - normal memory
> + *   - at most 512 kB large memory regions
> + *   - at most 32 shared memory regions per guest
> + * o FFA_MSG_SEND_DIRECT_REQ:
> + *   - only supported from a VM to an SP
> + *
> + * There are some large locked sections with ffa_tx_buffer_lock and
> + * ffa_rx_buffer_lock. Especially the ffa_tx_buffer_lock spinlock used
> + * around share_shm() is a very large locked section which can let one VM
> + * affect another VM.
>  */
> 
> #include 
> -- 
> 2.34.1
> 

Re: [XEN PATCH v11 11/14] xen/arm: ffa: improve lock granularity

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> The single lock in struct ffa_ctx is complemented with rx_lock and tx_lock.
> 
> The old lock is used for small critical sections, like increasing
> shm_count or adding another shm to shm_list.
> 
> rx_lock and tx_lock are only acquired using spin_trylock() which for
> well-behaving guests should always succeed. Guests using the RX and TX
> buffers are expected to serialize accesses before doing the FF-A
> request.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v10->v11
> - No changes except resolving conflicts since "xen/arm: ffa: support
>  sharing large memory ranges" was dropped.
> ---
> xen/arch/arm/tee/ffa.c | 107 +
> 1 file changed, 77 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 75700938c444..eb4a58fec470 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -363,6 +363,13 @@ struct ffa_ctx {
> struct list_head shm_list;
> /* Number of allocated shared memory object */
> unsigned int shm_count;
> +/*
> + * tx_lock is used to serialize access to tx
> + * rx_lock is used to serialize access to rx
> + * lock is used for the rest in this struct
> + */
> +spinlock_t tx_lock;
> +spinlock_t rx_lock;
> spinlock_t lock;
> };
> 
> @@ -768,7 +775,9 @@ static int32_t handle_partition_info_get(uint32_t w1, 
> uint32_t w2, uint32_t w3,
> if ( !ffa_rx )
> return FFA_RET_DENIED;
> 
> -spin_lock(>lock);
> +if ( !spin_trylock(>rx_lock) )
> +return FFA_RET_BUSY;
> +
> if ( !ctx->page_count || !ctx->rx_is_free )
> goto out;
> spin_lock(_rx_buffer_lock);
> @@ -819,7 +828,7 @@ out_rx_release:
> out_rx_buf_unlock:
> spin_unlock(_rx_buffer_lock);
> out:
> -spin_unlock(>lock);
> +spin_unlock(>rx_lock);
> 
> return ret;
> }
> @@ -830,13 +839,15 @@ static int32_t handle_rx_release(void)
> struct domain *d = current->domain;
> struct ffa_ctx *ctx = d->arch.tee;
> 
> -spin_lock(>lock);
> +if ( !spin_trylock(>rx_lock) )
> +return FFA_RET_BUSY;
> +
> if ( !ctx->page_count || ctx->rx_is_free )
> goto out;
> ret = FFA_RET_OK;
> ctx->rx_is_free = true;
> out:
> -spin_unlock(>lock);
> +spin_unlock(>rx_lock);
> 
> return ret;
> }
> @@ -947,21 +958,43 @@ static void put_shm_pages(struct ffa_shm_mem *shm)
> }
> }
> 
> +static bool inc_ctx_shm_count(struct ffa_ctx *ctx)
> +{
> +bool ret = true;
> +
> +spin_lock(>lock);
> +if (ctx->shm_count >= FFA_MAX_SHM_COUNT)
> +ret = false;
> +else
> +ctx->shm_count++;
> +spin_unlock(>lock);
> +
> +return ret;
> +}
> +
> +static void dec_ctx_shm_count(struct ffa_ctx *ctx)
> +{
> +spin_lock(>lock);
> +ASSERT(ctx->shm_count > 0);
> +ctx->shm_count--;
> +spin_unlock(>lock);
> +}
> +
> static struct ffa_shm_mem *alloc_ffa_shm_mem(struct ffa_ctx *ctx,
>  unsigned int page_count)
> {
> struct ffa_shm_mem *shm;
> 
> -if ( page_count >= FFA_MAX_SHM_PAGE_COUNT ||
> - ctx->shm_count >= FFA_MAX_SHM_COUNT )
> +if ( page_count >= FFA_MAX_SHM_PAGE_COUNT )
> +return NULL;
> +if ( !inc_ctx_shm_count(ctx) )
> return NULL;
> 
> shm = xzalloc_flex_struct(struct ffa_shm_mem, pages, page_count);
> if ( shm )
> -{
> -ctx->shm_count++;
> shm->page_count = page_count;
> -}
> +else
> +dec_ctx_shm_count(ctx);
> 
> return shm;
> }
> @@ -971,8 +1004,7 @@ static void free_ffa_shm_mem(struct ffa_ctx *ctx, struct 
> ffa_shm_mem *shm)
> if ( !shm )
> return;
> 
> -ASSERT(ctx->shm_count > 0);
> -ctx->shm_count--;
> +dec_ctx_shm_count(ctx);
> put_shm_pages(shm);
> xfree(shm);
> }
> @@ -1180,7 +1212,11 @@ static void handle_mem_share(struct cpu_user_regs 
> *regs)
> goto out_set_ret;
> }
> 
> -spin_lock(>lock);
> +if ( !spin_trylock(>tx_lock) )
> +{
> +ret = FFA_RET_BUSY;
> +goto out_set_ret;
> +}
> 
> if ( frag_len > ctx->page_count * FFA_PAGE_SIZE )
> goto out_unlock;
> @@ -1272,7 +1308,9 @@ static void handle_mem_share(struct cpu_user_regs *regs)
> if ( ret )
> goto out;
&

Re: [XEN PATCH v11 05/14] xen/arm: ffa: support guest FFA_PARTITION_INFO_GET

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> Adds support in the mediator to handle FFA_PARTITION_INFO_GET requests
> from a guest. The requests are forwarded to the SPMC and the response is
> translated according to the FF-A version in use by the guest.
> 
> Using FFA_PARTITION_INFO_GET changes the owner of the RX buffer to the
> caller (the guest in this case), so once it is done with the buffer it
> must be released using FFA_RX_RELEASE before another call can be made.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v10->v11
> - Fixing a typo in a comment and adding another comment as requested
> ---
> xen/arch/arm/tee/ffa.c | 134 +
> 1 file changed, 134 insertions(+)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 6c76c9885774..6c889bf97002 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -166,7 +166,18 @@
> #define FFA_MSG_SEND0x846EU
> #define FFA_MSG_POLL0x846AU
> 
> +/*
> + * Structs below ending with _1_0 are defined in FF-A-1.0-REL and
> + * structs ending with _1_1 are defined in FF-A-1.1-REL0.
> + */
> +
> /* Partition information descriptor */
> +struct ffa_partition_info_1_0 {
> +uint16_t id;
> +uint16_t execution_context;
> +uint32_t partition_properties;
> +};
> +
> struct ffa_partition_info_1_1 {
> uint16_t id;
> uint16_t execution_context;
> @@ -189,6 +200,7 @@ struct ffa_ctx {
>  */
> uint16_t create_signal_count;
> bool rx_is_free;
> +spinlock_t lock;
> };
> 
> /* Negotiated FF-A version to use with the SPMC */
> @@ -203,9 +215,15 @@ static uint16_t subscr_vm_destroyed_count __read_mostly;
> /*
>  * Our rx/tx buffers shared with the SPMC. FFA_RXTX_PAGE_COUNT is the
>  * number of pages used in each of these buffers.
> + *
> + * The RX buffer is protected from concurrent usage with ffa_rx_buffer_lock.
> + * Note that the SPMC is also tracking the ownership of our RX buffer so
> + * for calls which uses our RX buffer to deliver a result we must call
> + * ffa_rx_release() to let the SPMC know that we're done with the buffer.
>  */
> static void *ffa_rx __read_mostly;
> static void *ffa_tx __read_mostly;
> +static DEFINE_SPINLOCK(ffa_rx_buffer_lock);
> 
> static bool ffa_get_version(uint32_t *vers)
> {
> @@ -512,6 +530,103 @@ static uint32_t handle_rxtx_unmap(void)
> return FFA_RET_OK;
> }
> 
> +static int32_t handle_partition_info_get(uint32_t w1, uint32_t w2, uint32_t 
> w3,
> + uint32_t w4, uint32_t w5,
> + uint32_t *count)
> +{
> +int32_t ret = FFA_RET_DENIED;
> +struct domain *d = current->domain;
> +struct ffa_ctx *ctx = d->arch.tee;
> +
> +/*
> + * FF-A v1.0 has w5 MBZ while v1.1 allows
> + * FFA_PARTITION_INFO_GET_COUNT_FLAG to be non-zero.
> + *
> + * FFA_PARTITION_INFO_GET_COUNT is only using registers and not the
> + * rxtx buffer so do the partition_info_get directly.
> + */
> +if ( w5 == FFA_PARTITION_INFO_GET_COUNT_FLAG &&
> + ctx->guest_vers == FFA_VERSION_1_1 )
> +return ffa_partition_info_get(w1, w2, w3, w4, w5, count);
> +if ( w5 )
> +return FFA_RET_INVALID_PARAMETERS;
> +
> +if ( !ffa_rx )
> +return FFA_RET_DENIED;
> +
> +spin_lock(>lock);
> +if ( !ctx->page_count || !ctx->rx_is_free )
> +goto out;
> +spin_lock(_rx_buffer_lock);
> +ret = ffa_partition_info_get(w1, w2, w3, w4, w5, count);
> +if ( ret )
> +goto out_rx_buf_unlock;
> +/*
> + * ffa_partition_info_get() succeeded so we now own the RX buffer we
> + * share with the SPMC. We must give it back using ffa_rx_release()
> + * once we've copied the content.
> + */
> +
> +if ( ctx->guest_vers == FFA_VERSION_1_0 )
> +{
> +size_t n;
> +struct ffa_partition_info_1_1 *src = ffa_rx;
> +struct ffa_partition_info_1_0 *dst = ctx->rx;
> +
> +if ( ctx->page_count * FFA_PAGE_SIZE < *count * sizeof(*dst) )
> +{
> +ret = FFA_RET_NO_MEMORY;
> +goto out_rx_release;
> +}
> +
> +for ( n = 0; n < *count; n++ )
> +{
> +dst[n].id = src[n].id;
> +dst[n].execution_context = src[n].execution_context;
> +dst[n].partition_properties = src[n].partition_properties;
> +}
> +}
> +else
> +{
> +size_t sz = *c

Re: [XEN PATCH v11 04/14] xen/arm: ffa: support mapping guest RX/TX buffers

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> Adds support in the mediator to map and unmap the RX and TX buffers
> provided by the guest using the two FF-A functions FFA_RXTX_MAP and
> FFA_RXTX_UNMAP.
> 
> These buffer are later used to transmit data that cannot be passed in
> registers only.
> 
> Signed-off-by: Jens Wiklander 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v10->v11
> - Fixing a typo in a comment and adding a couple of newlines as requested
> ---
> xen/arch/arm/tee/ffa.c | 140 +
> 1 file changed, 140 insertions(+)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 5af3e5eedc88..6c76c9885774 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -74,6 +74,12 @@
>  */
> #define FFA_RXTX_PAGE_COUNT 1
> 
> +/*
> + * Limit the number of pages RX/TX buffers guests can map.
> + * TODO support a larger number.
> + */
> +#define FFA_MAX_RXTX_PAGE_COUNT 1
> +
> /*
>  * Flags and field values used for the MSG_SEND_DIRECT_REQ/RESP:
>  * BIT(31): Framework or partition message
> @@ -169,6 +175,12 @@ struct ffa_partition_info_1_1 {
> };
> 
> struct ffa_ctx {
> +void *rx;
> +const void *tx;
> +struct page_info *rx_pg;
> +struct page_info *tx_pg;
> +/* Number of 4kB pages in each of rx/rx_pg and tx/tx_pg */
> +unsigned int page_count;
> /* FF-A version used by the guest */
> uint32_t guest_vers;
> /*
> @@ -176,6 +188,7 @@ struct ffa_ctx {
>  * ffa_domain_teardown() to know which SPs need to be signalled.
>  */
> uint16_t create_signal_count;
> +bool rx_is_free;
> };
> 
> /* Negotiated FF-A version to use with the SPMC */
> @@ -371,6 +384,11 @@ static void set_regs(struct cpu_user_regs *regs, 
> register_t v0, register_t v1,
> set_user_reg(regs, 7, v7);
> }
> 
> +static void set_regs_error(struct cpu_user_regs *regs, uint32_t error_code)
> +{
> +set_regs(regs, FFA_ERROR, 0, error_code, 0, 0, 0, 0, 0);
> +}
> +
> static void set_regs_success(struct cpu_user_regs *regs, uint32_t w2,
>  uint32_t w3)
> {
> @@ -392,6 +410,108 @@ static void handle_version(struct cpu_user_regs *regs)
> set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> }
> 
> +static uint32_t handle_rxtx_map(uint32_t fid, register_t tx_addr,
> +register_t rx_addr, uint32_t page_count)
> +{
> +uint32_t ret = FFA_RET_INVALID_PARAMETERS;
> +struct domain *d = current->domain;
> +struct ffa_ctx *ctx = d->arch.tee;
> +struct page_info *tx_pg;
> +struct page_info *rx_pg;
> +p2m_type_t t;
> +void *rx;
> +void *tx;
> +
> +if ( !smccc_is_conv_64(fid) )
> +{
> +/*
> + * Calls using the 32-bit calling convention must ignore the upper
> + * 32 bits in the argument registers.
> + */
> +tx_addr &= UINT32_MAX;
> +rx_addr &= UINT32_MAX;
> +}
> +
> +if ( page_count > FFA_MAX_RXTX_PAGE_COUNT )
> +{
> +printk(XENLOG_ERR "ffa: RXTX_MAP: error: %u pages requested (limit 
> %u)\n",
> +   page_count, FFA_MAX_RXTX_PAGE_COUNT);
> +return FFA_RET_NOT_SUPPORTED;
> +}
> +
> +/* Already mapped */
> +if ( ctx->rx )
> +return FFA_RET_DENIED;
> +
> +tx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(tx_addr)), , 
> P2M_ALLOC);
> +if ( !tx_pg )
> +return FFA_RET_INVALID_PARAMETERS;
> +
> +/* Only normal RW RAM for now */
> +if ( t != p2m_ram_rw )
> +goto err_put_tx_pg;
> +
> +rx_pg = get_page_from_gfn(d, gfn_x(gaddr_to_gfn(rx_addr)), , 
> P2M_ALLOC);
> +if ( !tx_pg )
> +goto err_put_tx_pg;
> +
> +/* Only normal RW RAM for now */
> +if ( t != p2m_ram_rw )
> +goto err_put_rx_pg;
> +
> +tx = __map_domain_page_global(tx_pg);
> +if ( !tx )
> +goto err_put_rx_pg;
> +
> +rx = __map_domain_page_global(rx_pg);
> +if ( !rx )
> +goto err_unmap_tx;
> +
> +ctx->rx = rx;
> +ctx->tx = tx;
> +ctx->rx_pg = rx_pg;
> +ctx->tx_pg = tx_pg;
> +ctx->page_count = page_count;
> +ctx->rx_is_free = true;
> +return FFA_RET_OK;
> +
> +err_unmap_tx:
> +unmap_domain_page_global(tx);
> +err_put_rx_pg:
> +put_page(rx_pg);
> +err_put_tx_pg:
> +put_page(tx_pg);
> +
> +return ret;
> +}
> +
> +static void rxtx_unmap(struct ffa_ctx *ctx)
> +{
> +unmap_domain_page_globa

Re: [XEN PATCH v11 03/14] xen/arm: ffa: send guest events to Secure Partitions

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> The FF-A specification defines framework messages sent as direct
> requests when certain events occurs. For instance when a VM (guest) is
> created or destroyed. Only SPs which have subscribed to these events
> will receive them. An SP can subscribe to these messages in its
> partition properties.
> 
> Adds a check that the SP supports the needed FF-A features
> FFA_PARTITION_INFO_GET and FFA_RX_RELEASE.
> 
> The partition properties of each SP is retrieved with
> FFA_PARTITION_INFO_GET which returns the information in our RX buffer.
> Using FFA_PARTITION_INFO_GET changes the owner of the RX buffer to the
> caller (us), so once we're done with the buffer it must be released
> using FFA_RX_RELEASE before another call can be made.
> 
> Signed-off-by: Jens Wiklander 

One NIT after which might be fixed on commit.

With that fixed:
Reviewed-by: Bertrand Marquis 

> ---
> v10->v11:
> - Addressing comments and fixing a few style issues
> - Fixing how is_in_subscr_list() is used, it's supposed to take an
>  sp_id, not a vm_id.
> ---
> xen/arch/arm/tee/ffa.c | 234 -
> 1 file changed, 233 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index 072198a1326d..5af3e5eedc88 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -160,14 +160,33 @@
> #define FFA_MSG_SEND0x846EU
> #define FFA_MSG_POLL0x846AU
> 
> +/* Partition information descriptor */
> +struct ffa_partition_info_1_1 {
> +uint16_t id;
> +uint16_t execution_context;
> +uint32_t partition_properties;
> +uint8_t uuid[16];
> +};
> +
> struct ffa_ctx {
> /* FF-A version used by the guest */
> uint32_t guest_vers;
> +/*
> + * Number of SPs that we have sent a VM created signal to, used in
> + * ffa_domain_teardown() to know which SPs need to be signalled.
> + */
> +uint16_t create_signal_count;
> };
> 
> /* Negotiated FF-A version to use with the SPMC */
> static uint32_t __ro_after_init ffa_version;
> 
> +/* SPs subscribing to VM_CREATE and VM_DESTROYED events */
> +static uint16_t *subscr_vm_created __read_mostly;
> +static uint16_t subscr_vm_created_count __read_mostly;
> +static uint16_t *subscr_vm_destroyed __read_mostly;
> +static uint16_t subscr_vm_destroyed_count __read_mostly;
> +
> /*
>  * Our rx/tx buffers shared with the SPMC. FFA_RXTX_PAGE_COUNT is the
>  * number of pages used in each of these buffers.
> @@ -251,6 +270,87 @@ static int32_t ffa_rxtx_map(paddr_t tx_addr, paddr_t 
> rx_addr,
> return ffa_simple_call(FFA_RXTX_MAP_64, tx_addr, rx_addr, page_count, 0);
> }
> 
> +static int32_t ffa_partition_info_get(uint32_t w1, uint32_t w2, uint32_t w3,
> +  uint32_t w4, uint32_t w5,
> +  uint32_t *count)
> +{
> +const struct arm_smccc_1_2_regs arg = {
> +.a0 = FFA_PARTITION_INFO_GET,
> +.a1 = w1,
> +.a2 = w2,
> +.a3 = w3,
> +.a4 = w4,
> +.a5 = w5,
> +};
> +struct arm_smccc_1_2_regs resp;
> +uint32_t ret;
> +
> +arm_smccc_1_2_smc(, );
> +
> +ret = get_ffa_ret_code();
> +if ( !ret )
> +*count = resp.a2;
> +
> +return ret;
> +}
> +
> +static int32_t ffa_rx_release(void)
> +{
> +return ffa_simple_call(FFA_RX_RELEASE, 0, 0, 0, 0);
> +}
> +
> +static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
> +  uint8_t msg)
> +{
> +uint32_t exp_resp = FFA_MSG_FLAG_FRAMEWORK;
> +unsigned int retry_count = 0;
> +int32_t res;
> +
> +if ( msg == FFA_MSG_SEND_VM_CREATED )
> +exp_resp |= FFA_MSG_RESP_VM_CREATED;
> +else if ( msg == FFA_MSG_SEND_VM_DESTROYED )
> +exp_resp |= FFA_MSG_RESP_VM_DESTROYED;
> +else
> +return FFA_RET_INVALID_PARAMETERS;
> +
> +do {
> +const struct arm_smccc_1_2_regs arg = {
> +.a0 = FFA_MSG_SEND_DIRECT_REQ_32,
> +.a1 = sp_id,
> +.a2 = FFA_MSG_FLAG_FRAMEWORK | msg,
> +.a5 = vm_id,
> +};
> +struct arm_smccc_1_2_regs resp;
> +
> +arm_smccc_1_2_smc(, );
> +if ( resp.a0 != FFA_MSG_SEND_DIRECT_RESP_32 || resp.a2 != exp_resp )
> +{
> +/*
> + * This is an invalid response, likely due to some error in the
> + * implementation of the ABI.
> + */
> +return FFA_RET_INVALID_PARAMETE

Re: [XEN PATCH v11 01/14] xen/arm: ffa: add direct request support

[Bertrand Marquis]

Hi Jens,

> On 31 Jul 2023, at 14:15, Jens Wiklander  wrote:
> 
> Adds support for sending a FF-A direct request. Checks that the SP also
> supports handling a 32-bit direct request. 64-bit direct requests are
> not used by the mediator itself so there is not need to check for that.
> 
> Signed-off-by: Jens Wiklander 
> Reviewed-by: Henry Wang 

Reviewed-by: Bertrand Marquis 

Cheers
Bertrand

> ---
> v10->v11
> - In handle_msg_send_direct_req(), replaced the "arg" with "resp" at the
>  default: label in the switch statement.
> ---
> xen/arch/arm/tee/ffa.c | 113 +
> 1 file changed, 113 insertions(+)
> 
> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
> index e157ed20ad8b..961a8c052f59 100644
> --- a/xen/arch/arm/tee/ffa.c
> +++ b/xen/arch/arm/tee/ffa.c
> @@ -181,6 +181,56 @@ static bool ffa_get_version(uint32_t *vers)
> return true;
> }
> 
> +static int32_t get_ffa_ret_code(const struct arm_smccc_1_2_regs *resp)
> +{
> +switch ( resp->a0 )
> +{
> +case FFA_ERROR:
> +if ( resp->a2 )
> +return resp->a2;
> +else
> +return FFA_RET_NOT_SUPPORTED;
> +case FFA_SUCCESS_32:
> +case FFA_SUCCESS_64:
> +return FFA_RET_OK;
> +default:
> +return FFA_RET_NOT_SUPPORTED;
> +}
> +}
> +
> +static int32_t ffa_simple_call(uint32_t fid, register_t a1, register_t a2,
> +   register_t a3, register_t a4)
> +{
> +const struct arm_smccc_1_2_regs arg = {
> +.a0 = fid,
> +.a1 = a1,
> +.a2 = a2,
> +.a3 = a3,
> +.a4 = a4,
> +};
> +struct arm_smccc_1_2_regs resp;
> +
> +arm_smccc_1_2_smc(, );
> +
> +return get_ffa_ret_code();
> +}
> +
> +static int32_t ffa_features(uint32_t id)
> +{
> +return ffa_simple_call(FFA_FEATURES, id, 0, 0, 0);
> +}
> +
> +static bool check_mandatory_feature(uint32_t id)
> +{
> +int32_t ret = ffa_features(id);
> +
> +if ( ret )
> +printk(XENLOG_ERR "ffa: mandatory feature id %#x missing: error 
> %d\n",
> +   id, ret);
> +
> +return !ret;
> +}
> +
> static uint16_t get_vm_id(const struct domain *d)
> {
> /* +1 since 0 is reserved for the hypervisor in FF-A */
> @@ -222,6 +272,57 @@ static void handle_version(struct cpu_user_regs *regs)
> set_regs(regs, vers, 0, 0, 0, 0, 0, 0, 0);
> }
> 
> +static void handle_msg_send_direct_req(struct cpu_user_regs *regs, uint32_t 
> fid)
> +{
> +struct arm_smccc_1_2_regs arg = { .a0 = fid, };
> +struct arm_smccc_1_2_regs resp = { };
> +struct domain *d = current->domain;
> +uint32_t src_dst;
> +uint64_t mask;
> +
> +if ( smccc_is_conv_64(fid) )
> +mask = GENMASK_ULL(63, 0);
> +else
> +mask = GENMASK_ULL(31, 0);
> +
> +src_dst = get_user_reg(regs, 1);
> +if ( (src_dst >> 16) != get_vm_id(d) )
> +{
> +resp.a0 = FFA_ERROR;
> +resp.a2 = FFA_RET_INVALID_PARAMETERS;
> +goto out;
> +}
> +
> +arg.a1 = src_dst;
> +arg.a2 = get_user_reg(regs, 2) & mask;
> +arg.a3 = get_user_reg(regs, 3) & mask;
> +arg.a4 = get_user_reg(regs, 4) & mask;
> +arg.a5 = get_user_reg(regs, 5) & mask;
> +arg.a6 = get_user_reg(regs, 6) & mask;
> +arg.a7 = get_user_reg(regs, 7) & mask;
> +
> +arm_smccc_1_2_smc(, );
> +switch ( resp.a0 )
> +{
> +case FFA_ERROR:
> +case FFA_SUCCESS_32:
> +case FFA_SUCCESS_64:
> +case FFA_MSG_SEND_DIRECT_RESP_32:
> +case FFA_MSG_SEND_DIRECT_RESP_64:
> +break;
> +default:
> +/* Bad fid, report back to the caller. */
> +memset(, 0, sizeof(resp));
> +resp.a0 = FFA_ERROR;
> +resp.a1 = src_dst;
> +resp.a2 = FFA_RET_ABORTED;
> +}
> +
> +out:
> +set_regs(regs, resp.a0, resp.a1 & mask, resp.a2 & mask, resp.a3 & mask,
> + resp.a4 & mask, resp.a5 & mask, resp.a6 & mask, resp.a7 & mask);
> +}
> +
> static bool ffa_handle_call(struct cpu_user_regs *regs)
> {
> uint32_t fid = get_user_reg(regs, 0);
> @@ -239,6 +340,10 @@ static bool ffa_handle_call(struct cpu_user_regs *regs)
> case FFA_ID_GET:
> set_regs_success(regs, get_vm_id(d), 0);
> return true;
> +case FFA_MSG_SEND_DIRECT_REQ_32:
> +case FFA_MSG_SEND_DIRECT_REQ_64:
> +handle_msg_send_direct_req(regs, fid);
> +return true;
> 
> default:
> gprintk(XENLOG_ERR, "ffa: unhandled fid 0x%x\n", fid);
> @@ -331,6 +436,14 @@ static bool ffa_probe(void)
> printk(XENLOG_INFO "ARM FF-A Firmware version %u.%u\n",
>major_vers, minor_vers);
> 
> +/*
> + * 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
> + * features supported.
> + */
> +if ( !check_mandatory_feature(FFA_MSG_SEND_DIRECT_REQ_32) )
> +return false;
> +
> ffa_version = vers;
> 
> return true;
> -- 
> 2.34.1
>