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

[Eric Blake]

[trimming cc's]

On 04/28/2017 10:01 AM, Markus Armbruster wrote:
> Eric Blake <address@hidden> 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.

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.

I'm probably up to the task of coding this, rather than waiting for a
solution from Pavel; but I would rather have some guidance on preferred
direction, particularly the understanding of how much we care about
cross-version replay (which is admittedly a tougher thing than
cross-version migration), so I don't waste time by starting coding down
a wrong direction.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature