From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUUYk-0000pl-Ig for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:24:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUUYg-0000mv-1X for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:24:34 -0500 Received: from [199.232.76.173] (port=44131 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUUYf-0000mm-T9 for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:24:29 -0500 Received: from mail-qy0-f189.google.com ([209.85.221.189]:52752) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUUYf-0006Nw-KE for qemu-devel@nongnu.org; Mon, 11 Jan 2010 19:24:29 -0500 Received: by qyk27 with SMTP id 27so9705379qyk.20 for ; Mon, 11 Jan 2010 16:24:28 -0800 (PST) Message-ID: <4B4BC138.1000500@codemonkey.ws> Date: Mon, 11 Jan 2010 18:24:24 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] QMP forward compatibility support References: <20100111163422.0d86d2bb@doriath> <4B4B748B.6010008@codemonkey.ws> <20100111220436.14c662a5@doriath> In-Reply-To: <20100111220436.14c662a5@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: armbru@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On 01/11/2010 06:04 PM, Luiz Capitulino wrote: > > As async messages were one of the reasons for having QMP, I thought > that there was a consensus that making it part of the "original" > protocol was ok, meaning that they would be always available. > > That's the only reason. > Right, but then it's not a capability, it's a core feature. I just think it would be odd to advertise something as a capability and have it not behave like other ones. >>> 3. We should add command(s) to enable/disable protocol features >>> >>> 4. Proper feature negotiation is done in pause mode. That's, clients >>> interested in enabling new protocol features should start QEMU in >>> pause mode and enable the features they are interested in using >>> >>> >> Why does this matter? >> >> We should be careful to support connecting to a VM long after it's been >> started so any requirement like this is likely to cause trouble. >> > If I understood Markus's concerns correctly, he thinks that feature > negotiation should happen before the protocol is "running", ie. make > it part of the initial handshake. > I think forcing the negotiation before executing any commands is a good idea. But I don't think requiring the guest not to be running is necessary or even useful. You don't want to have to support disabling and enabling features in the middle of a protocol session because then you have to deal with weird semantics. > Now, if everything is disabled by default and qemu might be running > already, do we really need to have a handshake? > I think it's valuable to have a discrete period of time when no commands have been executed where features can be enabled. It simplifies some nasty edge conditions regarding enabling features while there are outstanding commands in flight. Regards, Anthony Liguori