qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 1/5] Implement GIC-500 base class


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v8 1/5] Implement GIC-500 base class
Date: Mon, 10 Aug 2015 18:23:42 +0100

On 10 August 2015 at 13:06, Pavel Fedin <address@hidden> wrote:
> From: Shlomo Pongratz <address@hidden>
>
> 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 <address@hidden>
> Signed-off-by: Pavel Fedin <address@hidden>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]