[Qemu-devel] Re: Two QMP events issues

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Feb 08, 2010 at 11:41:45AM -0200, Luiz Capitulino wrote:
> 
>  Hi there,
> 
>  I have two not so related QMP events issues two discuss, but I will talk about
> them in the same email to avoid starting two threads.
> 
>  The first problem is wrt the STOP event. Right now it's only emitted if it's
> triggered through qemu_system_vmstop_request(), which afaik will only be
> called if CONFIG_IOTHREAD is enabled (nonsense, yes).
> 
>  The best fix I can think of is to move the STOP event down to do_vm_stop().
> We could even have a 'reason' data member with the string representation of
> the EXCP_ macros. Looks like this is the right thing do to.
> 
>  There's a problem, though. Migration and block subsystems also do vm_stop(0).
> The former's reason seems to be 'stop to be loaded' and the latter is 'can't
> continue' on disk errors. Note that the block subsystem already has its own
> event for disk errors.
> 
>  So, my solution is to not generate the STOP event on vm_stop(0). If any
> vm_stop(0) user (eg. migration) wants to generate events they should create
> the appropriate EXCP_ macro for that.
> 
>  Does this look good?
> 
>  The second problem is about the watchdog device. I have been asked to
> add events for the watchdog's device actions (see
> hw/watchdog.c:watchdog_perform_action()).
> 
>  Issue is: most of those events directly map to QEMU's events already
> generated by QMP, such as RESET, SHUTDOWN, POWEROFF etc.
> 
>  We have two solutions:
> 
> 1. Introduce watchdog's own events. This is easy to do, but will
> generate two QMP events for most actions. Eg. the watchdog's WDT_RESET
> action will generate a QMP event for WDT_RESET and will generate
> another RESET event when this action takes place in QEMU
> 
> 2. Add a 'source' data member to all events requested via the
> qemu_system_* functions, so that we can have a 'wachtdog' source and
> only one event is triggered. This will require a more complex change
> and maybe some hacks will be needed (eg. for vm_stop())
> 
>  Opinions?

For further backgrou, the key end goal here is that in a QMP client, upon
receipt of the  'RESET' event, we need to reliably & immediately determine
why it  occurred. eg, triggered by watchdog, or by guest OS request. There
are actually 3 possible sequences

 - WATCHDOG + action=reset, followed by RESET.  Assuming no intervening 
   event can occurr, the client can merely record 'WATCHDOG' and interpret
   it when it gets the immediately following 'RESET' event

 - RESET, followed by WATCHDOG + action=reset. The client doesn't know
   the reason for the RESET and can't wait arbitrarily for WATCHDOG since
   there might never be one arriving.

 - RESET + source=watchdog. Client directly sees the reason

The second scenario is the one I'd like us to avoid at all costs, since it
will require the client to introduce arbitrary delays in processing events
to determine cause. The first is slightly inconvenient, but doable if we 
can assume no intervening events will occur, between WATCHDOG and the
RESET events. The last is obviously simplest for the clients.

This question is also pretty relevant for Luiz's previous posting of disk
block I/O errors, since one of those actions  can result in a PAUSE event

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|