Re: [Qemu-devel] replay help [was: [PATCH v5 3/4] shutdown: Add source information to SHUTDOWN and RESET]

["Pavel Dovgalyuk" <dovgaluk@ispras.ru>]

> From: Eric Blake [mailto:eblake@redhat.com]
> On 04/28/2017 10:01 AM, Markus Armbruster wrote:
> > Eric Blake <eblake@redhat.com> writes:
> >
> >> Libvirt would like to be able to distinguish between a SHUTDOWN
> >> event triggered solely by guest request and one triggered by a
> >> SIGTERM or other action on the host.  While qemu_kill_report() is
> >> already able to tell whether a shutdown was triggered by a host
> >> signal (but NOT by a host UI event, such as clicking the X on
> >> the window), that information was then lost after being printed
> >> to stderr.  The previous patch prepped things to use an enum
> >> internally; now it's time to wire it up through all callers, and
> >> to extend the SHUTDOWN and RESET events to report the details.
> >>
> 
> >> The replay driver needs a followup patch if we want to be able to
> >> faithfully replay the difference between a host- and guest-initiated
> >> shutdown (for now, the replayed event is always attributed to host).
> >
> > I'd prefer to get this right from the start, but that requires input
> > from replay guys.
> >
> > Scandalously, replay/ is not covered by MAINTAINERS.
> > scripts/get_maintainers.pl blames it on Pavel Dovgalyuk (cc'ed), and git
> > shows recent activity.  Pavel, please post a suitable patch to
> > MAINTAINERS, and please help us figure out what to do about replaying
> > reset here.
> 
> In particular, my questions include:
> 
> How sensitive is the enum ReplayEvents in replay-internal.h to
> additions? Do we have to worry about cross-version compatibility (where
> we can only add new events at the end), or can we reorder things at
> will?  I suspect that depends on whether you ever plan to replay a
> script recorded by old qemu while running new qemu.

There is no cross-version compatibility at all.
Changing any virtual device behavior makes whole previously recorded
replay log unusable.
Therefore we can add any events and update REPLAY_VERSION to prevent
cross-version launches.

> One idea would be to carve out a range of new enums in ReplayEvents,
> similar to how you have a range of CHECKPOINT_COUNT enums carved out;
> the range would be large enough to encode each cause of shutdown, and
> then you just map the range back into a reset request with the right
> cause. Another would be to modify the replay script file format: right
> now, it records a single byte for a shutdown request, but a single new
> enum triggers that we now read a second byte for the cause (where the
> second byte is directly the cause).  If replaying old streams matters,
> we still have to burn a new enum (so that you can tell the difference
> between old stream with no cause occupying one byte, vs. new stream with
> second byte giving the cause); if cross-version qemu doesn't matter (ie.
> upgrading qemu can invalidate all previously captured replay streams),
> then this version would better be served by repurposing the existing
> EVENT_SHUTDOWN enum in-place.

Replaying old stream does not matter.
I prefer new enum, because it will simplify comparisons and switches.

Pavel Dovgalyuk