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

From: Julien Grall <julien.grall@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, Vijay Kilari <vijay.kilari@gmail.com>
Subject: Re: [PATCH 04/28] ARM: GICv3 ITS: allocate device and collection table
Date: Thu, 23 Mar 2017 18:08:17 +0000	[thread overview]
Message-ID: <884aa304-2d67-5ce0-c0b4-e1527b0ad4d5@arm.com> (raw)
In-Reply-To: <1b7335d2-58a1-6cdb-b8a8-7917455019e2@arm.com>

On 23/03/17 18:06, Andre Przywara wrote:
> Hi,

Hi Andre,

> 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.

Replacing NR_CPUS by nr_cpu_ids would have addressed my comment and 
requiring less keystrokes than writing this e-mail.

Cheers,

-- 
Julien Grall

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