Re: [Qemu-devel] [PATCH 2/3] qemu-char: add -chardev exit-on-eof option

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 07/25/2014 02:12 AM, Markus Armbruster wrote:
>> Stefan Hajnoczi <address@hidden> writes:
>> 
>>> When QEMU is executed as part of a test case or from a script, it is
>>> usually desirable to exit if the parent process terminates.  This
>>> ensures that "leaked" QEMU processes do not continue consuming resources
>>> after their parent has died.
>
>>>  ##
>>> -{ 'type': 'ChardevHostdev', 'data': { 'device' : 'str' } }
>>> +{ 'type': 'ChardevHostdev', 'data': { 'device' : 'str',
>>> +                                      '*exit-on-eof' : 'bool' } }
>>>  
>>>  ##
>>>  # @ChardevSocket:
>> 
>> Any use cases beyond libqtest?
>
> Libvirt probably won't use it for normal guests (we don't want to kill
> qemu just because the monitor disconnects), but does have the notion of
> an autodestroy guest where it might be useful (we WANT the guest to go
> away if libvirtd dies early).  In fact, autodestroy guests are used
> during migration - we want to kill qemu on the destination side if
> libvirtd dies before the source side finishes sending the migration
> stream.  But in that scenario, once migration succeeds, libvirt has to
> be able to convert an autodestroy guest back into a normal guest that no
> longer disappears when libvirtd does; would this be something that QMP
> can toggle the state of this attribute on the fly?  Perhaps through qom-set?

After migration completes, execution moves from source to target.
Wouldn't you want to switch off target auto-destruct together with that
move, atomically?

>> If no, should this be x-exit-on-eof?
>> 
>> Hmm, looks like there's no precedence for x- in QAPI.
>
> Ah, but we do.  For example, x-rdma-pin-all in MigrationCapability in
> qemu 1.7; which has later been removed.
>
> However, we also have precedence of actions in QAPI that are very
> unlikely to be used outside of qtest, but which are not marked
> experimental; for example, the 'Abort' action in 'transaction' will
> probably never be used by libvirt

Arguably not a conscious decision to make it ABI forever, more a case of
nobody thought about *not* making it ABI :)

>                                   (but as I type that, the thought in
> the back of my mind is that I could possibly do some sort of feature
> probing by setting up a transaction that will abort, and distinguish
> between whether the transaction aborted or whether it errored out
> because the feature I'm probing for isn't present).
>
> I'm fine leaving this as plain 'exit-on-eof'.

I don't really mind this instance, but I'm a bit concerned about rank
ABI growth.