Il 22/11/2012 17:58, Luiz Capitulino ha scritto: >>>> It seems like mon->mc->command_mode is set wrong, looking at >>>> qmp_cmd_mode and its callers. Luiz may have more ideas. >>> >>> Checking. What I've just found is that qmp_capabilites will fail if the >>> VM is stopped (!?). >> >> It's a regression somewhere. I doubt it's qmp, but could be. >> >> Here are the symptoms, Doc: >> >> 1. Start qemu and stop it right away. Connect to the QMP socket and you >> won't get qmp's greeting >> >> 2. Start qemu, connect to the QMP socket and run the qmp_capabilities >> command. Then stop qemu and disconnect from the qmp socket and connect >> again: you'll see you're still in the previous session >> >> I do not get this with qemu 1.0. >> >> Dietmar got this because the suspend command automatically stops the VM >> after migration... >> >> Bisecting... > > Didn't try to understand what's wrong with it, but bisect brings: > > commit ac4119c023c72b15f54238af43e4a178fcf41494 > Author: Jan Kiszka <jan.kis...@siemens.com> > Date: Fri Oct 12 09:52:49 2012 +0200 > > chardev: Use timer instead of bottom-half to postpone open event > > As the block layer may decide to flush bottom-halfs while the machine is > still initializing (e.g. to read geometry data from the disk), our > postponed open event may be processed before the last frontend > registered with a muxed chardev. > > Until the semantics of BHs have been clarified, use an expired timer to > achieve the same effect (suggested by Paolo Bonzini). This requires to > perform the alarm timer initialization earlier as otherwise timer > subsystem can be used before being ready. > > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
Ouch, in retrospect it actually makes sense since this patch uses a vm_clock timer. Elementary, Watson... :) I don't think there is a fix, short of reverting this commit. Paolo
