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

Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version


  • To: "Halder, Ayan Kumar" <ayankuma@xxxxxxx>, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 6 Mar 2026 10:02:22 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=D5hzusVCfC0hMW+mRZ01vIshdf1XTGt3KIlNr3V9kfM=; b=Mpt85slZvWSkbZdrm/zE6NTLI8h06TgORQkLwSgBrXd+xQKDLet/oiL9xI08sASUzF+VAtV7sR4uLdlj2VpY7aJUL08fg4QOL7Am251nbKIWr9E1/a623r+33Za4jStaAF4bqYQWm7w5k8+u3HIJMGWVvHNxjvU6/+nFQeWQ+o5xZOmdRWFrxbSkTbJMRMb6p4mGQmhcJ546P27FPKfQTmJrGDAiA18wlP8l8t8Cj7P49zG6Xy//KVtgHPS2ty9X1KeTBcXvSNutLe6P0+6pcRD1KOe6Rs7rRZglEgjEkXBq897GrEwNhxL0Iq+VaLwxNrrYvhR7FUDfk8OoZPrfNA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UHRB4tOHW8NkU8SE62QanmkqP14nmWvWPwhtYJo9PYcBWmrP/WBPen2G8OiE9NCMsadBBrMskVWsohTVjGE4eeRCSl+IJvl7Mox+76635D06frJmXILETd+VCxbG67Q5NFUT7N6R4QzBp7h7K8wkHs8QBaiAx6GoF4PN3KO8Q/Uxu5c4JCkcLTbBx/IctBXuKj1bP8h+Gay2qb8b7QEXKdRHc0Isqmie///IU6/tNHe9epuAYr8WVL0/jalkc5u/yeJ7A88QwJvcIemsuock4jv9KuI6xEW0ar1VC7AQULMIUqz9z2kg4sN9eE3eU0FY+eMSYgJSnHSA5av6t9iemA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 06 Mar 2026 10:02:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 06/03/2026 9:59 am, Halder, Ayan Kumar wrote:
> Hi Andrew,
>
> On 05/03/2026 23:01, Andrew Cooper wrote:
>> On 05/03/2026 7:57 pm, Ayan Kumar Halder wrote:
>>> The lr_mask bitmap tracks which List Registers (LRs) are in use for
>>> virtual interrupt injection. Previously, lr_mask always used uint64_t
>>> (8 bytes) to support the maximum number of LRs across both GIC
>>> versions.
>>>
>>> However, GICv2 and GICv3 have different hardware limits:
>>> - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits)
>>> - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits)
>>>
>>> This patch introduces conditional compilation to optimize lr_mask size:
>>> - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs
>>> - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs
>>>
>>> With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr()
>>> cannot have a value > 15. Thus, it should not possible to hit the
>>> BUG() in the default case.
>>>
>>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
>> What does this actually get you?
>>
>> Because it doesn't actually eliminate the BUG()s you reference.
>
> As lr is obtained from lr_mask, see the snippet from gic_find_unused_lr()
>
>         for_each_set_bit ( used_lr, *lr_mask )
>         {
>             struct gic_lr lr_val;
>
>             gic_hw_ops->read_lr(used_lr, &lr_val);
>             if ( lr_val.virq == p->irq )
>                 return used_lr;
>         }
>
> If lr_mask is 16 bits, then used_lr should not exceed 15. That is my
> thinking.

Sure, but what does that actually get you?

It doesn't get you a compiled difference.  It can't DCE the boundary checks.

So right now, it looks like it's complexity for no gain.

~Andrew



 


Rackspace

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