From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqYFf-0001Lt-Rl for qemu-devel@nongnu.org; Thu, 26 Jan 2012 17:57:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqYFe-0006Fa-IA for qemu-devel@nongnu.org; Thu, 26 Jan 2012 17:57:07 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:53295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqYFe-0006FT-Bs for qemu-devel@nongnu.org; Thu, 26 Jan 2012 17:57:06 -0500 Received: by dajr28 with SMTP id r28so1117801daj.4 for ; Thu, 26 Jan 2012 14:57:05 -0800 (PST) Message-ID: <4F21DA3D.9020203@codemonkey.ws> Date: Thu, 26 Jan 2012 16:57:01 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20120126144632.GM21211@redhat.com> <4F216EAB.2000707@redhat.com> <20120126173533.0079dc98@doriath.home> In-Reply-To: <20120126173533.0079dc98@doriath.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] [PATCH RFC 0/4] Allow hibernation on guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: libvir-list@redhat.com, Michal Privoznik , Eric Blake , QEMU Developers , mdroth@linux.vnet.ibm.com On 01/26/2012 01:35 PM, Luiz Capitulino wrote: > On Thu, 26 Jan 2012 08:18:03 -0700 > Eric Blake wrote: > >> [adding qemu-devel] >> >> On 01/26/2012 07:46 AM, Daniel P. Berrange wrote: >>>> One thing, that you'll probably notice is this >>>> 'set-support-level' command. Basically, it tells GA what qemu version >>>> is it running on. Ideally, this should be done as soon as >>>> GA starts up. However, that cannot be determined from outside >>>> world as GA doesn't emit any events yet. >>>> Ideally^2 this command should be left out as it should be qemu >>>> who tells its own agent this kind of information. >>>> Anyway, I was going to call this command in qemuProcess{Startup, >>>> Reconnect,Attach}, but it won't work. We need to un-pause guest CPUs >>>> so guest can boot and start GA, but that implies returning from qemuProcess*. >>>> >>>> So I am setting this just before 'guest-suspend' command, as >>>> there is one more thing about GA. It is unable to remember anything >>>> upon its restart (GA process). Which has BTW show flaw >>>> in our current code with FS freeze& thaw. If we freeze guest >>>> FS, and somebody restart GA, the simple FS Thaw will not succeed as >>>> GA thinks FS are not frozen. But that's a different cup of tea. >>>> >>>> Because of what written above, we need to call set-level >>>> on every suspend. >>> >>> >>> IMHO all this says that the 'set-level' command is a conceptually >>> unfixably broken design& should be killed in QEMU before it turns >>> into an even bigger mess. > > Can you elaborate on this? Michal and I talked on irc about making the > compatibility level persistent, would that help? > >>> Once we're in a situation where we need to call 'set-level' prior >>> to every single invocation, you might as well just allow the QEMU >>> version number to be passed in directly as an arg to the command >>> you are running directly thus avoiding this horrificness. >> >> Qemu folks, would you care to chime in on this? >> >> Exactly how is the set-level command supposed to work? As I understand >> it, the goal is that if the guest has qemu-ga 1.1 installed, but is >> being run by qemu 1.0, then we want to ensure that any guest agent >> command supported by qemu-ga 1.1 but requiring features of qemu not >> present in qemu 1.0 will be properly rejected. > > Not exactly, the default support of qemu-ga is qemu 1.0. This means that by > default qemu-ga will only support qemu 1.0 even when running on qemu 2.0. This > way the set-support-level command allows you to specify that qemu 2.0 features > are supported. Version numbers are meaningless. What happens when a bunch of features get backported by RHEL such that qemu-ga 1.0 ends up being a frankenstein version of 2.0? The feature negotiation mechanism we have in QMP is the existence of a command. If we're in a position where we're trying to disable part of a command, it simply means that we should have multiple commands such that we can just remove the disabled part entirely. Regards, Anthony Liguori