|
[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
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |