> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Friday, September 09, 2011 8:50 PM
>
> On 09/09/2011 13:18, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx> wrote:
>
> > Hello,
> >
> > We have recently had a support escalation about Xen-4.1.1 being unable
> > to boot on HP BL460c G7 blades. The problem turned out to be a null
> > function pointer deference (ns_to_tick in cpu_idle.c) during early boot
> > of dom0, in the set_cx_pminfo function.
> >
> > I applied your patch, changeset 23662:2faba14bac13, about initializing
> > default C state information, and this appears to have fixed the problem.
> >
> > However, I see in the patch that setting up the function pointers
> > (ns_to_tick, tick_to_ns etc) is predicated on the hypercall coming in on
> > CPU0.
>
> Firstly, it's predicated on the hypercall addressing CPU0, rather than being
> executed on CPU0. Secondly, the cpuidle_init_cpu() functiomn is *also*
> called from the CPU-hotplug path in Xen, and is called directly from the
> presmp_initcall path for CPU0. I don't know why it is called both on a
> hypercall path and on a hotplug path, it seems weird. But anyhow, this means
> that the function pointers will guaranteed get set up early during Xen boot?
yes. do it in hypercall path is b/c present ACPI processors may not be online
by Xen yet. do it in CPU-hotplug path is b/c we may want to do some resource
housekeeping according to CPU-hotplug event, though now only CPU_ONLINE
is handled. It's a bit overkilled, but should be ok for saneness reason.
Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home