[domU suspend/resume] Interrupts and event channel code

[Jean-Yves Migeon <jean-yves.migeon%espci.fr@localhost>]

Hi list,

Questions today relate to interrupt/event code for xenbus 
(arch/xen/xenbus/xenbus_*.c files).

There are parts in the interrupt code that tests whether an interrupt is 
"installed" (== has an event associated to it) for xenbus/xenstore 
access by looking at the value of the start_info.store_evtchn element, 
against 0. It concerns dom0 code (see xenbus_attach() code, with 
DOM0OPS) and domU (when testing xenbus_irq variable).

Questions:
- a value of 0 is considered invalid for an event channel? I read that 
the ports were indexed from 0 to 255 (or 511, for x86_64; with XEN3).
- what is the purpose of the xenbus_irq variable, found in 
arch/xen/xenbus/xenbus_comms.c? Basically, it is initialized (at 
compilation) to 0, and contains later the same value as 
xen_start_info.store_evtchn variable. Upon xenbus initialization during 
attach, xenbus_irq is checked that way (line 224):

...
       if (xenbus_irq)
               event_remove_handler(xenbus_irq, wake_waiting, NULL);
...

Which basically removes the handler for xenstored wakeup() calls, in 
case xenbus_irq() != 0. Any code path I am not aware of, which 
manipulates the xenstored handler and xenbus_irq before xenbus attach? 
From my PoV, the event_remove_handler() will never be called here.

BTW, shouldn't the handler removal operation rather be part of a 
_detach() routine for xenbus?

Lastly, arch/xen/xenbus/xenbus_probe.c, in xenbus_probe_init(). This 
function is called through a kthread_create(), but returns without using 
kthread_exit() in case we are booting a dom0 wtih a kernel not compiled 
with DOM0OPS option. For such a case, what would be the kthread_exit() 
value to use as parameter? Man page for kthread states that the func 
must never return, but use kthread_exit() to terminate properly.

Thanks for your patience, and answers :)

Cheers

--
Jean-Yves Migeon
jean-yves.migeon%espci.fr@localhost