Hi Michal, > The patch is correct, but what we already have is qemuExtDevicesStop() > being called from qemuProcessStop(). The former will eventually call > qemuTPMEmulatorStop() which should kill the swtmp process, shouldn't it? I'd missed this and that's great to hear, because it means the upstream bug (i.e. swtpm behaving as though --terminate was given even when it wasn't) can be fixed now, without breaking libvirt. > Or this patch is there to kill swtmp earlier, i.e. as soon as it sees > HUP on the socket? That's the thing; this is already (incorrectly) happening right now: swtpm is self-terminating as soon as it sees HUP on the socket, even though --terminate wasn't given. In other words, we're currently seeing --terminate behavior *without* --terminate. Due to this upstream bug, I suspect swtpm is already shutting itself down by the time libvirt executes qemuExtDevicesStop(). Once the upstream bug is fixed, swtpm will no longer self-terminate on HUP *unless* --terminate was given. If libvirt doesn't add --terminate, swtpm will then stay up (as it should) and be killed by qemuExtDevicesStop() instead. Does that make sense? While the end result will ultimately be the same, I'd still argue that it's a good idea for libvirt to start invoking swtpm with --terminate since (a) it's free, (b) it's more graceful, (c) it takes some responsibility off libvirt, and (d) it adds an extra layer of redundancy by allowing swtpm to try to shut itself down first and, if that fails, have libvirt's qemuExtDevicesStop() kill it. Nick
