Re: [domU suspend/resume] Interrupts and event channel code

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, May 09, 2008 at 05:06:31PM +0200, Jean-Yves Migeon wrote:
> 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).

I don't think even channel 0 is ever used.

> - 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.

I think it's related to suspend/resume, precisely. When xb_init_comms()
is called again after a resume, the event channel may have changed, so
you have to remove the old one before setting up a new one.
Maybe on NetBSD it can be done in a different way.


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

For suspend/resume you don't want to detach/reattach xenbus, because it'd
also means to detach/reattach the child devices.

> 
> 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.

I guess it's be 0

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--