diff options
author | John Snow <jsnow@redhat.com> | 2021-11-18 15:46:18 -0500 |
---|---|---|
committer | John Snow <jsnow@redhat.com> | 2021-11-22 18:41:17 -0500 |
commit | 1611e6cf4e7163f6102b37010a8b7e7120f468b5 (patch) | |
tree | db1453698855108b08315aa1c743e677de21568c /target/mips/kvm.c | |
parent | b1ca99199320fcc010f407b84ac00d96e7e4baa1 (diff) | |
download | qemu-1611e6cf4e7163f6102b37010a8b7e7120f468b5.zip qemu-1611e6cf4e7163f6102b37010a8b7e7120f468b5.tar.gz qemu-1611e6cf4e7163f6102b37010a8b7e7120f468b5.tar.bz2 |
python/machine: handle "fast" QEMU terminations
In the case that the QEMU process actually launches -- but then dies so
quickly that we can't establish a QMP connection to it -- QEMUMachine
currently calls _post_shutdown() assuming that it never launched the VM
process.
This isn't true, though: it "merely" may have failed to establish a QMP
connection and the process is in the middle of its own exit path.
If we don't wait for the subprocess, the caller may get a bogus `None`
return for .exitcode(). This behavior was observed from
device-crash-test; after the switch to Async QMP, the timings were
changed such that it was now seemingly possible to witness the failure
of "vm.launch()" *prior* to the exitcode becoming available.
The semantic of the `_launched` property is changed in this
patch. Instead of representing the condition "launch() executed
successfully", it will now represent "has forked a child process
successfully". This way, wait() when called in the exit path won't
become a no-op.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Willian Rampazzo <willianr@redhat.com>
Message-id: 20211118204620.1897674-6-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'target/mips/kvm.c')
0 files changed, 0 insertions, 0 deletions