[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [domU suspend/resume] Interrupts and event channel code
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).
> - 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
Main Index |
Thread Index |