> From: Eric Blake [mailto:ebl...@redhat.com] > On 04/28/2017 10:01 AM, Markus Armbruster wrote: > > Eric Blake <ebl...@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
