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

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

On Mon, May 12, 2008 at 05:18:03PM +0200, Jean-Yves Migeon wrote:
> Manuel Bouyer wrote:
> >>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.
> >  
> Huh, I just noticed I was not clear on this point.
> 
> We have two possibilities here (as there are many parts elsewhere, like 
> console, where we can do with two different ways):
> 1 - either check upon resuming that the event channels/parameters have 
> changed, and update the values accordingly (done in the resume handler code)
> 2 - or invalidate them when calling suspend handlers, and reinstate them 
> upon resume.
> 
> Option 2 looks cleaner to me. It would make sense to invalidate events 
> associated to comms between dom0 and domUs at the same time (especially 
> when we are detaching wd* block devices, for example).

Sure, Option 2 looks better. 

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