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

Re: [PATCH v2 01/10] xen/arm: gicv3: refactor obtaining GIC addresses for common operations


  • To: Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Leonid Komarianskyi <Leonid_Komarianskyi@xxxxxxxx>
  • Date: Fri, 22 Aug 2025 10:09:20 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Dr429g1Sn1INzynHm9pWT2y0tCDebL6oWyiqr1pmEyY=; b=PldXlCedKJSEvDEQlTDbkJ810OvOPQc8e0e1Mvbhy8wbNufvWCooM265nm1Wx7UAoDd3FJON2u0lzPvQbk33vujeWsfyjH3rHbbKFDpeOOdSzfb5Fi6KD/Sl/MaLvcXMdPLOAk0oKOsJxk7sknGiSXyOWdmCGcCFjmcvVZk2brNoKhHgSRCCqXS+mZCzt+zuD9Naj3imfsD71Ai8kX1NHenZRJ4HWZlhA5WXR/Qa4TIKJW+phhySgSkiw8IOG4eCuhW4LKik0tFeFrkj/yHRrj82k5VsHp9umvU5w0RNlXBCGTvtN+daZW7/yf9cHjn1Cx88+AWwd+AyR+M+EBMo3g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lMnKUbEgVqSDpy08fsb+iqpCMHKA0hv8pwWSVwhPSBd7bTgq+kNaBikR2+jfvzVY8H8YO+8Qgav8pGdyb10eraXU0K4nvplPHWd86iqSuyYX7xEmuUpc66yXcOQ0dII2OQ69nQDJCCuey3F1juxYxpNpOs7wfkd2LdlUH7mUdItNRa8zRhM6ypotWgqXMhUVzr0XfvsrNiFTnP6HrlSLHnw6Sm/3eDM3dlJU5ecbIOHzyICERuK4hIzIbcEgneTSQvxJlAnX1XUHD903qEHwRZE/NCh+gdtEml1kIMIhsVsCyQC85pGvRPgFHSnmHcZfBvFF56KV5Eus9Hl9+ERdyg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 22 Aug 2025 10:09:38 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHcB5d7cCAQRdJCgUKSzBGsZt4ytbRtXheAgAEbjYCAAAhPgIAACIOA
  • Thread-topic: [PATCH v2 01/10] xen/arm: gicv3: refactor obtaining GIC addresses for common operations

Hi Julien,

On 22.08.25 12:38, Julien Grall wrote:
> Hi Leonid,
> 
> On 22/08/2025 10:09, Leonid Komarianskyi wrote:
>  > Thank you for your close review.>>> ---
>>>>    xen/arch/arm/gic-v3.c          | 99 +++++++++++++++++++++ 
>>>> +------------
>>>>    xen/arch/arm/include/asm/irq.h |  1 +
>>>>    2 files changed, 67 insertions(+), 33 deletions(-)
>>>>
>>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>>> index cd3e1acf79..8fd78aba44 100644
>>>> --- a/xen/arch/arm/gic-v3.c
>>>> +++ b/xen/arch/arm/gic-v3.c
>>>> @@ -445,17 +445,62 @@ static void gicv3_dump_state(const struct vcpu 
>>>> *v)
>>>>        }
>>>>    }
>>>> +static void __iomem *get_addr_by_offset(struct irq_desc *irqd, u32
>>>> offset)
>>>> +{
>>>> +    switch ( irqd->irq )
>>>> +    {
>>>> +    case 0 ... (NR_GIC_LOCAL_IRQS - 1):
>>>> +        switch ( offset )
>>>> +        {
>>>> +        case GICD_ISENABLER:
>>>> +        case GICD_ICENABLER:
>>>> +        case GICD_ISPENDR:
>>>> +        case GICD_ICPENDR:
>>>> +        case GICD_ISACTIVER:
>>>> +        case GICD_ICACTIVER:
>>>> +            return (GICD_RDIST_SGI_BASE + offset);
>>>> +        case GICD_ICFGR:
>>>> +            return (GICD_RDIST_SGI_BASE + GICR_ICFGR1);
>>>> +        case GICD_IPRIORITYR:
>>>> +            return (GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + irqd- 
>>>> >irq);
>>>> +        default:
>>>> +            break;
>>>> +        }
>>>> +    case NR_GIC_LOCAL_IRQS ... SPI_MAX_INTID:
>>>> +        switch ( offset )
>>>> +        {
>>>> +        case GICD_ISENABLER:
>>>> +        case GICD_ICENABLER:
>>>> +        case GICD_ISPENDR:
>>>> +        case GICD_ICPENDR:
>>>> +        case GICD_ISACTIVER:
>>>> +        case GICD_ICACTIVER:
>>>> +            return (GICD + offset + (irqd->irq / 32) * 4);
>>>> +        case GICD_ICFGR:
>>>> +            return (GICD + GICD_ICFGR + (irqd->irq / 16) * 4);
>>>> +        case GICD_IROUTER:
>>>> +            return (GICD + GICD_IROUTER + irqd->irq * 8);
>>>> +        case GICD_IPRIORITYR:
>>>> +            return (GICD + GICD_IPRIORITYR + irqd->irq);
>>>> +        default:
>>>> +            break;
>>>> +        }
>>>> +    default:
>>>> +        break;
>>>> +    }
>>>> +
>>>> +    /* Something went wrong, we shouldn't be able to reach here */
>>>   > +    panic("Invalid offset 0x%x for IRQ#%d", offset, irqd->irq);
>>>
>>> ... I still quite concerned about using panic here. We need to try to
>>> handle the error more gracefully in production.
>>>
>>> Cheers,
>>>
>>
>> I was thinking about this again, and maybe it would be better to change
>> the panic into simply printing an error using printk(XENLOG_G_ERR ...)
>> and adding proper checks to ensure the return value is not NULL in the
>> callers.
> 
> Given the error is not meant to happen, after the printk() I would add 
> an ASSERT_UNREACHABLE() so we can catch issue in DEBUG build more easily.
> 

Okay, so I will change the panic to printk + ASSERT_UNREACHABLE() in V3. 
Thank you.

>> Also, in the case of gicv3_peek_irq, which must return a boolean value
>> (due to the generic API for gicv3_read_pending_state), we could return
>> false with an additional warning message that we are unable to read the
>> actual value due to incorrect parameters; therefore, we return false.
>> What do you think about this approach?
> 
> It makes sense to read false as the interrupt technically doesn't exist. 
> But I don't think we should add an extra warning. The one in 
> get_addr_by_offset() should be sufficient.
> 
> Cheers,
> 

Understood, thank you again.

Best regards,
Leonid

 


Rackspace

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