[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-devel
Subject:    RE: [Xen-devel] [PATCH] ioemu-remote: check shutdown_requested timely.
From:       "Cui, Dexuan" <dexuan.cui () intel ! com>
Date:       2008-12-31 2:22:25
Message-ID: EADF0A36011179459010BDF5142A4575045D51A9 () pdsmsx502 ! ccr ! corp ! intel ! com
[Download RAW message or body]

Ian Jackson wrote:
> Cui, Dexuan writes ("[Xen-devel] [PATCH] ioemu-remote:
> > After a recent merge of the ioemu-remote tree several weeks ago, I
> > find in main() -> termsig_seup(), ioemu sets a SIGHUP handler that
> > sets a global variable shutdown_requested to 1, but ioemu doesn't
> > check the variable and as a result, ioemu wouldn't terminate when
> > xend sends a SIGHUP to it; finally xend has to send a SIGKILL to it
> > in 10 seconds. The small patch adds a check to terminate ioemu
> > timely.
> 
> I can reproduce the problem you report here - the symptoms I see are
> log messages in xend.log and that `xm destroy' is slow.
> 
> But while it's true that the main loop in vl.c doesn't check
> qemu_shutdown_requested, that main loop is not compiled in in qemu-dm.
The vl.c: main_loop() checks qemu_shutdown_requested but we don't use it; what we use \
is helper2.c:main_loop() which doesn't exit() when the variable is 1.

> Did you test your fix ?  Your fix would also seem to make qemu-dm exit
> immediately if the domain powers off even if on_poweroff=preserve.
Yes, I tested it and don't meet with the issue you mention. I think when we specify \
'on_poweroff=preserve' in hvm config file, xend wouldn't send SIGHUP to ioemu at all \
when guest itself powers off normally.

> The root cause of the problem seems to be that upstream qemu installs
> signal handlers for the common terminating signals, which simply
> request shutdown.  That's not appropriate for us because xend sends us
> a signal when it wants us to really die.  So I have disabled that and
> the fix should be in the usual places soon.
I see you fix in the qemu-xen-unstable tree. I think it's a better fix.

Thanks,
 -- Dexuan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


[prev in list] [next in list] [prev in thread] [next in thread]