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

Re: [Xen-devel] [PATCH RFC 5/7] xen: arm: rewrite start of day page table and cpu bring up



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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.