From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NV6ge-00069p-Es for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:07:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NV6gZ-00067v-Ts for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:07:15 -0500 Received: from [199.232.76.173] (port=39583 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NV6gZ-00067m-IU for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:07:11 -0500 Received: from mx20.gnu.org ([199.232.41.8]:8845) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NV6gW-0007C6-Qp for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:07:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NV6gO-0002EQ-II for qemu-devel@nongnu.org; Wed, 13 Jan 2010 12:07:00 -0500 Date: Wed, 13 Jan 2010 15:06:43 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] QMP forward compatibility support Message-ID: <20100113150643.24509d01@doriath> In-Reply-To: References: <20100111163422.0d86d2bb@doriath> <4B4B748B.6010008@codemonkey.ws> <20100111220436.14c662a5@doriath> <4B4BC138.1000500@codemonkey.ws> <20100112101102.396b15fb@doriath> 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: Markus Armbruster Cc: aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org, avi@redhat.com On Wed, 13 Jan 2010 17:53:38 +0100 Markus Armbruster wrote: > Luiz Capitulino writes: > > > 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. > > If it's optional, leave it off by default because the consensus seems to > be to leave all optional features off by default. > > It should be optional if we want to support clients that don't want it. > I don't think coping with it would be a terrible burden on clients, but > neither is having to ask for it. Personally, I'd make it optional. Ok, will do. > >> >>> 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 > > Really "any command"? What about commands to enable/disable protocol > capabilities? I think that playing with some protocol bits might be safe, like enabling async messages. I'm not saying this is a good practice, but forbidding it seems a bit extreme at first.