From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUfag-00017W-1Y for qemu-devel@nongnu.org; Tue, 12 Jan 2010 07:11:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUfab-00015i-GM for qemu-devel@nongnu.org; Tue, 12 Jan 2010 07:11:17 -0500 Received: from [199.232.76.173] (port=56176 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUfab-00015b-8V for qemu-devel@nongnu.org; Tue, 12 Jan 2010 07:11:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1026) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUfaa-0007V4-QL for qemu-devel@nongnu.org; Tue, 12 Jan 2010 07:11:13 -0500 Date: Tue, 12 Jan 2010 10:11:02 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] QMP forward compatibility support Message-ID: <20100112101102.396b15fb@doriath> In-Reply-To: <4B4BC138.1000500@codemonkey.ws> References: <20100111163422.0d86d2bb@doriath> <4B4B748B.6010008@codemonkey.ws> <20100111220436.14c662a5@doriath> <4B4BC138.1000500@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: armbru@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Mon, 11 Jan 2010 18:24:24 -0600 Anthony Liguori wrote: > 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. Ok, so options are: call it a core feature and don't change anything or call it a capability and make it behave like any other capability. What's the better? Should we vote? :) Daniel seems to prefer the later. > >>> 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. That's true, but I thought that doing that with pause mode was going to be better because it didn't require any change on QMP side. If this is a bad approach, then I was wrong. Now, making this part of the initial handshake brings some more design decisions and by making async messages a capability helps to test them. I'm thinking in something like this: 1. Connection is made, the greeting message is sent and QMP is in 'handshake mode' 2. In this mode only commands to enable/disable protocol capabilities are allowed 3. When the client is done with the setup, it issues the command 'enable-qmp', which puts the protocol into 'running mode', where any command is accepted