Re: [XenARM] [RFC PATCH 2/2] ARM: SMP support for mach-virt

[Will Deacon <will.deacon@xxxxxxx>]

On Mon, Dec 03, 2012 at 09:55:35PM +0000, Rob Herring wrote:
> On 12/03/2012 11:52 AM, Will Deacon wrote:
> > From: Marc Zyngier <marc.zyngier@xxxxxxx>
> > 
> > This patch adds support for SMP to mach-virt.
> > 
> > Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
> > Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
> > 

[...]

> > +/*
> > + * This provides a "holding pen" into which all secondary cores are held
> > + * until we're ready for them to initialise.
> > + */
> > +ENTRY(virt_secondary_startup)
> > +   mrc     p15, 0, r0, c0, c0, 5
> > +   and     r0, r0, #15
> > +   adr     r4, 1f
> > +   ldmia   r4, {r5, r6}
> > +   sub     r4, r4, r5
> > +   add     r6, r6, r4
> > +pen:       ldr     r7, [r6]
> > +   cmp     r7, r0
> > +   bne     pen
> 
> Why is the pen is needed? It should only be needed for hotplug on
> systems that can't reset their cores. I'd hope you could design good
> virtual h/w.

It's not so much about designing good virtual h/w as it is avoiding tying
the platform to it. What we don't want is to mandate that in order to boot
this machine, you *must* implement an emulation of some virtual
power-controller or SMP booting device. If we go down that route, there's
less advantage from having the virtual platform in the first place.

There's also less of a problem with the pen approach to booting because
ultimately the virtual CPUs executing there are just pthreads and will be
scheduled appropriately by the hypervisor (in contrast to a real system
where there may be concerns about power consumption and memory bandwidth).

For hotplug, sure, we could have an *optional* virtio-based device for
dealing with that if we want to. We could even have some early probing code
for it and use it for SMP boot if we find a matching DT node, but we'd still
need to keep the pen code lying around as a fallback.

> > +/*
> > + * Enumerate the possible CPU set from the device tree.
> > + */
> > +static void __init virt_smp_init_cpus(void)
> > +{
> > +   const char *enable_method;
> > +   struct device_node *dn = NULL;
> > +   int cpu = 0;
> > +   u32 release_addr;
> > +
> > +   while ((dn = of_find_node_by_type(dn, "cpu"))) {
> > +           if (cpu >= NR_CPUS)
> > +                   goto next;
> > +
> > +           /*
> > +            * We currently support only the "spin-table" enable-method.
> > +            */
> > +           enable_method = of_get_property(dn, "enable-method", NULL);
> > +           if (!enable_method || strcmp(enable_method, "spin-table")) {
> 
> Are these documented?

It's part of the EPAPR spec iirc and follows the booting protocol used by
arm64.

Will

_______________________________________________
Xen-arm mailing list
Xen-arm@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm