[libvirt] [PATCH] Ignore qemu STOP event when stopping CPUs

Luiz Capitulino lcapitulino at redhat.com
Tue Apr 27 19:09:06 UTC 2010


On Tue, 27 Apr 2010 20:01:06 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:

> On Tue, Apr 27, 2010 at 03:50:20PM -0300, Luiz Capitulino wrote:
> > On Tue, 27 Apr 2010 11:20:39 +0200
> > jdenemar at redhat.com wrote:
> > 
> > > From: Jiri Denemark <jdenemar at redhat.com>
> > > 
> > > With JSON qemu monitor, we get a STOP event from qemu whenever qemu
> > > stops guests CPUs. The downside of it is that vm->state is changed to
> > > PAUSED and a new generic paused event is send to applications. However,
> > > when we ask qemu to stop the CPUs we are not really interested in qemu
> > > event and we usually want to issue a more specific event.
> > 
> >  Can you give an example? Say, "guest is suspended"?
> > 
> >  If this is the case, something you have to consider is whether libvirt
> > should add high-level events on top of low-level ones.
> > 
> >  Or, to make it more general, what should libvirt report to applications
> > wrt events?
> > 
> > > By setting vm->status to PAUSED before actually sending the request to
> > > qemu (and resetting it back if the request fails) we can ignore the
> > > event since the event handler does nothing when the guest is already
> > > paused. This solution is quite hacky but unfortunately it's the best
> > > solution which I was able to come up with and it doesn't introduce a
> > > race condition.
> > 
> >  You could extend the low-level driver to accept a mask of events to
> > be ignored.
> 
> The core problem here is that QEMU only emits a STOP event, with no
> corresponding CONT event. If QEMU had been doing both, this patch
> would not be neccessary, because we'd see both transitions from QEMU
> instead of just one direction.

 Oh, I already have a patch that introduces it, it's part of the
savevm/loadvm/delvm series (which is giving me a bit of headache ATM).

 I will cherry-pick the patch and submit it later today.




More information about the libvir-list mailing list