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
