Re: [Xen-devel] [PATCH 04/28] ARM: GICv3 ITS: allocate device and collection table

[Andre Przywara <andre.przywara@xxxxxxx>]

Hi,

On 06/02/17 17:43, Julien Grall wrote:
> Hi,
> 
> On 30/01/17 18:31, Andre Przywara wrote:
>> +int gicv3_its_init(struct host_its *hw_its)
>> +{
>> +    uint64_t reg;
>> +    int i;
>> +
>> +    hw_its->its_base = ioremap_nocache(hw_its->addr, hw_its->size);
>> +    if ( !hw_its->its_base )
>> +        return -ENOMEM;
>> +
>> +    for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
>> +    {
>> +        void __iomem *basereg = hw_its->its_base + GITS_BASER0 + i * 8;
>> +        int type;
>> +
>> +        reg = readq_relaxed(basereg);
>> +        type = (reg & GITS_BASER_TYPE_MASK) >> GITS_BASER_TYPE_SHIFT;
>> +        switch ( type )
>> +        {
>> +        case GITS_BASER_TYPE_NONE:
>> +            continue;
>> +        case GITS_BASER_TYPE_DEVICE:
>> +            /* TODO: find some better way of limiting the number of
>> devices */
>> +            its_map_baser(basereg, reg, BIT(max_its_device_bits));
>> +            break;
>> +        case GITS_BASER_TYPE_COLLECTION:
>> +            its_map_baser(basereg, reg, NR_CPUS);
> 
> And I forgot to mention about the collection. Same remark as for the
> device collection, NR_CPUS is the maximum size.

NR_CPUS is 128, entry size for each collection is probably around 8 or
16 bytes, if at all. This gives me half a page, worst case.
The granularity of the table memory handed to the ITS is (64K|16K|4K),
so as we only hand over whole pages to the ITS, I don't see how we can
save memory here.
Beside, we have other memory issues to worry about than this single 64K
allocated at boot time.

So if you don't mind, I'd just keep it as it is. I am happy to revisit
this once NR_CPUS gets significantly increased.

Cheers,
Andre.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel