From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [PATCH RFC 5/7] xen: arm: rewrite start of day page
	table and cpu bring up
Date: Thu, 19 Sep 2013 14:36:50 +0100
Message-ID: <20130919133650.GG52431@ocelot.phlegethon.org>
References: <1379381846.11304.73.camel@hastur.hellion.org.uk>
	<1379382050-11821-5-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <1379382050-11821-5-git-send-email-ian.campbell@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <ian.campbell@citrix.com>
Cc: julien.grall@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

At 02:40 +0100 on 17 Sep (1379385648), Ian Campbell wrote:
> +    /* Clear the copy of the boot pagetables. Each secondary CPU
> +     * rebuilds these itself (see head.S) */
> +    memset(boot_pgtable, 0x0, PAGE_SIZE);
> +    memset(boot_second, 0x0, PAGE_SIZE);

Does this need a cache flush?  I.e., could a later eviction of these
zeros race with a secondary CPU building its boot pagetables?

> +    /* All cpus start on boot page tables, then switch to cpu0's (both
> +     * in head.S), finally onto their own in mmu_init_secondary_cpu. */
> +    init_ttbr = (uintptr_t) THIS_CPU_PGTABLE + phys_offset;
> +    flush_xen_dcache(init_ttbr);

Do secondary CPUs need to switch twice?  As long as they're coming up
one at a time we could set init_ttbr to each CPU's allocated pagetables
in __cpu_up().  Or can we not guarantee to bring them up one at a time?
In which case, are their boot_pgtable manipulations safe against each
other?

> -void __init
> -make_cpus_ready(unsigned int max_cpus, unsigned long boot_phys_offset)
> -{
> -    unsigned long *gate;
> -    paddr_t gate_pa;
> -    int i;
> -
> -    printk("Waiting for %i other CPUs to be ready\n", max_cpus - 1);
> -    /* We use the unrelocated copy of smp_up_cpu as that's the one the
> -     * others can see. */ 
> -    gate_pa = ((paddr_t) (unsigned long) &smp_up_cpu) + boot_phys_offset;
> -    gate = map_domain_page(gate_pa >> PAGE_SHIFT) + (gate_pa & ~PAGE_MASK); 
> -    for ( i = 1; i < max_cpus; i++ )
> -    {
> -        /* Tell the next CPU to get ready */
> -        /* TODO: handle boards where CPUIDs are not contiguous */
> -        *gate = i;
> -        flush_xen_dcache(*gate);
> -        isb();
> -        sev();
> -        /* And wait for it to respond */
> -        while ( ready_cpus < i )
> -            smp_rmb();

You can also drop the declaration of ready_cpus above and the code to
increment it in head.S (x2).

> +#ifdef CONFIG_ARM_32
> +int platform_cpu_init(int cpu);
> +int platform_cpu_up(int cpu);

arch_cpu_{init,up} are marked __init, but platform_cpu_{init,up} are
not.  Is that deliberate?

Cheers,

Tim.