Re: Query about cpuidle

[Keir Fraser <keir.xen@gmail.com>]

On 09/09/2011 13:18, "Andrew Cooper" <andrew.cooper3@citrix.com> 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?

I can only sympathise and agree that the code is complicated and opaque,
however.

 -- Keir

>  What guarantees are in place to ensure that these function
> pointers get set up?  I cant see anything obvious from the code, but
> have to admit that the null pointer deference appears to have gone away.
> 
> Thanks in advance,