qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] Add minimal Vexpress Cortex A15 support
Date: Tue, 06 Dec 2011 14:28:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/01/2011 03:37 AM, address@hidden wrote:
> From: Bill Carson <address@hidden>
>
> This patch adds minimal codes to support A15  which enables ARM KVM could
> run Guest OS build with Versatile Express Cortex-A15x4 tile.
>
> +
> +static inline int
> +gic_get_current_cpu(void)
> +{
> +  return cpu_single_env->cpu_index;
> +}

Bad indents.

> +/* Per-CPU private memory mapped IO.  */
> +static uint64_t a15mpcore_priv_read(void *opaque, target_phys_addr_t offset,
> +                                 unsigned size)
> +{
> +    a15mpcore_priv_state *s = (a15mpcore_priv_state *)opaque;
> +    int id;
> +
> +    offset &= 0xfff;
> +    /* Interrupt controller.  */
> +    if (offset < 0x200) {
> +     id = gic_get_current_cpu();
> +     } else {
> +        id = (offset - 0x200) >> 8;
> +        if (id >= s->num_cpu) {
> +                return 0;
> +        }
> +    }
> +     return gic_cpu_read(&s->gic, id, offset & 0xff);
> +}

Very bad indents.  Detab your files.

> +
> +static void a15mpcore_priv_write(void *opaque, target_phys_addr_t offset,
> +                              uint64_t value, unsigned size)
> +{
> +    a15mpcore_priv_state *s = (a15mpcore_priv_state *)opaque;
> +    int id;
> +     
> +    offset &= 0xfff;
> +    /* Interrupt controller.  */
> +    if (offset < 0x200) {
> +     id = gic_get_current_cpu();
> +     } else {
> +        id = (offset - 0x200) >> 8;
> +        if (id >= s->num_cpu) {
> +                return 0;
> +        }
> +    }
> +     return gic_cpu_write(&s->gic, id, offset & 0xff, value);
> +}

Here, too.

> +static void a15mpcore_priv_map_setup(a15mpcore_priv_state *s)
> +{
> +    memory_region_init(&s->container, "mpcode-priv-container", 0x3000);
> +    memory_region_init_io(&s->iomem, &mpcore_priv_ops, s, "mpcode-priv",
> +                          0x1000);
> +    memory_region_add_subregion(&s->container, 0x2000, &s->iomem);
> +    memory_region_add_subregion(&s->container, 0x1000, &s->gic.iomem);
> +}

mpcode or mpcore?

> +    /* RAM is from 0x80000000 upwards. The bottom 64MB of the
> +     * address space should in theory be remappable to various
> +     * things including ROM or RAM; we always map the RAM there.
> +     */
> +    cpu_register_physical_memory(0x0, low_ram_size, ram_offset | IO_MEM_RAM);
> +    cpu_register_physical_memory(0x80000000, ram_size,
> +                                 ram_offset | IO_MEM_RAM);
> +

Use memory_region_init_ram()/memory_region_add_subregion() instead.

> +
> +    /* ??? Hack to map an additional page of ram for the secondary CPU
> +       startup code.  I guess this works on real hardware because the
> +       BootROM happens to be in ROM/flash or in memory that isn't clobbered
> +       until after Linux boots the secondary CPUs.  */
> +    ram_offset = qemu_ram_alloc(NULL, "vexpress.hack", 0x1000);
> +    cpu_register_physical_memory(SMP_BOOT_ADDR, 0x1000,
> +                                 ram_offset | IO_MEM_RAM);

Here, too.

It would be better to unhack this; short-term hacks tend to remain in
the long term, and even after they're fixed we keep them for backwards
compatibility.


-- 
error compiling committee.c: too many arguments to function




reply via email to

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