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

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


  • To: Jens Wiklander <jens.wiklander@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 26 Apr 2024 15:12:03 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PXwJYQS01UcnKyoOjSHUMqYGBLfsV7F/f3PgZkXkt+A=; b=XOfUj3LvPrynoRa/b/X7k9PE76u8hVOYRnk0fM7UBR+UBG2JoKY6/evyY2MmnEIGfFS27z/bomoS1c7Lj9wnopiI+hyU7PkHbgwz9NGSbCkRDkdv3X7KRBEj7GF8KZGw0u49JMxUSOXFCHyr2oBnyybuCoTltFEdq6Y67vt3l4AXFwyb0rnRoBhQQyOAC91uWLl8z8jids3Q6Qor7UBdVtPE3se21N4Tr7Mc60cyb2f84wBZPmeyV801AYJ3WsXaaJ0JOWLPuiaI7toKJfNRLxGYnxA0G/uBGjdu21WBFWUi3jztyZC58yeKYPwKf3qMJkyGMJEBCEREi0pkeBwn/w==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=PXwJYQS01UcnKyoOjSHUMqYGBLfsV7F/f3PgZkXkt+A=; b=bASh29yZxMna5F45R6H/MhumZo0mLDwZUTcH4LskZT2VtVGpK6M0A8m1kfAYBQryA1rzR8hhBi3J7XfZw40q91U3565BVVahvE4eRyDfWfmVk1vdEsSnIbwx8uAZTpsgQ7/837J41xtBCNJjKgXaDbffxPxLWkcuS4BKQIh+hz1lV4djlS0wcoslGHPv0COjuoayK+fl7GX4iEYFybmXg/fDjBoC7pO1lwp6cn4bLmKizJ4up8hzVbO1ErEjUpO9crwnvLBjO0O45fJ6bBgm1+/RlDLZMjOOdg3zBhXAejawE95Sf6ReIUMHMgNJBGi2YGfL76WG56DtrbcOkOKN9w==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=h6zGBh4XdcKWSQgBeR0j6I5r21wlWezQy37Br5AY9MP1qmJpuxhtH7gtYNR//Lzd4goA5TzUUTEIwklaDekPQk48uTvyr97fGvO7ZcZZNMuCw8y34GlMXjLuVg+SBgkOnfJLamn1iySaBjxKU5hMRfAAhw0hxbRIiOkd1fqmMmgeK7V1bCxQ1OIn7C8QzHfhVRd5JuwLt5tDghl/ElaXcyQQ6wwe96rYCbq0y3tr+MjNDck3vfznJA9TMBLVH1Vjj9dEracXqwnl09Fnzk18M06CPGqNLKUupZKgENykMpm/C6BEs61AkJLOm0q43cz64CplqK066OVnZiuIRgyzNg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hi7vUejcwL+VhND0oH/k5iTs5RB2K9s8TM5kNYVCV9C5JLIyOni+G6wfM/LlhFSY5Ryr5/nH0Vf8wgF2bs2SVQDy8qC8gZdrMFPE3R4yvmavQLRKa9EMRu9Ywf1ut5A8554SXX5KNKOuTDAf2j9M3mTMrSxeiyVCmxaWkJwHuv0sR+EJztDiu1vHZ4tpMgsWW68uy6EtkCWxL9L9TZuoNVuiohTfETFXo2NzHup4Kr4cJT6ADr6ATrKoxq9k81NnJHFXJ6OEFQHbH++PW9znq1i5qwEYxRigkN5uf4nmiZjai+PIPJkhafvd1S01aS0u4WPq5recsZyy9YTz0ECElQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "patches@xxxxxxxxxx" <patches@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 26 Apr 2024 15:12:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHal7ZoS0Rs3weazUuhKfXitmlnMLF6RnOAgAAvzwCAAAIygIAAA5kAgAACj4CAAAXVAIAAJEOA
  • Thread-topic: [XEN PATCH v3 5/5] xen/arm: ffa: support notification

Hi Jens,

> On 26 Apr 2024, at 15:02, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> 
> On Fri, Apr 26, 2024 at 2:41 PM Bertrand Marquis
> <Bertrand.Marquis@xxxxxxx> wrote:
>> 
>> Hi Jens,
>> 
>>> On 26 Apr 2024, at 14:32, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On Fri, Apr 26, 2024 at 2:19 PM Bertrand Marquis
>>> <Bertrand.Marquis@xxxxxxx> wrote:
>>>> 
>>>> Hi Jens,
>>>> 
>>>>> On 26 Apr 2024, at 14:11, Jens Wiklander <jens.wiklander@xxxxxxxxxx> 
>>>>> wrote:
>>>>> 
>>>>> Hi Bertrand,
>>>>> 
>>>>> On Fri, Apr 26, 2024 at 11:20 AM Bertrand Marquis
>>>>> <Bertrand.Marquis@xxxxxxx> wrote:
>>>>>> 
>>>>>> Hi Jens,
>>>>>> 
>>>>>>> On 26 Apr 2024, at 10:47, Jens Wiklander <jens.wiklander@xxxxxxxxxx> 
>>>>>>> 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(&arg, &resp);
>>>>>>> +    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, &irq_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 &irq_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



 


Rackspace

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