On 10 August 2015 at 13:06, Pavel Fedin <p.fe...@samsung.com> wrote:
> From: Shlomo Pongratz <shlomo.pongr...@huawei.com>
>
> This class is to be used by both software and KVM implementations of GICv3
>
> Currently it is mostly a placeholder, but in future it is supposed to hold
> qemu's representation of GICv3 state, which is necessary for migration.
>
> Signed-off-by: Shlomo Pongratz <shlomo.pongr...@huawei.com>
> Signed-off-by: Pavel Fedin <p.fe...@samsung.com>
> + memory_region_init_io(&s->iomem_dist, OBJECT(s), ops, s,
> + "gicv3_dist", 0x10000);
> + memory_region_init_io(&s->iomem_redist, OBJECT(s), ops ? &ops[1] : NULL,
> s,
> + "gicv3_redist", 0x800000);
Why is the redistributor region so huge? The spec says a
redistributor has four 64KB frames in its memory map:
* RD_base
* SGI_base
* VLPI_base
* Reserved
which is a lot smaller than this memory region...
> +
> +/* Maximum number of possible interrupts, determined by the GIC architecture
> */
> +#define GICV3_MAXIRQ 1020
The comment could use updating, because part of the point of GICv3
is to not have that limit...
> +#define GICV3_NCPU 64
What is imposing this NCPU limit?
> +
> +typedef struct GICv3State {
> + /*< private >*/
> + SysBusDevice parent_obj;
> + /*< public >*/
> +
> + qemu_irq parent_irq[GICV3_NCPU];
> + qemu_irq parent_fiq[GICV3_NCPU];
We should be allocating memory for the right number of irqs
and fiqs based on the number of actual CPUs, because we don't
really want a compile-time arbitrary limit on NCPUs.
thanks
-- PMM
