From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NeUva-0004e5-UF for qemu-devel@nongnu.org; Mon, 08 Feb 2010 09:49:30 -0500 Received: from [199.232.76.173] (port=54444 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NeUva-0004ds-LD for qemu-devel@nongnu.org; Mon, 08 Feb 2010 09:49:30 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NeUvV-0001QB-Cd for qemu-devel@nongnu.org; Mon, 08 Feb 2010 09:49:30 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]:57222) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NeUvU-0001PZ-MI for qemu-devel@nongnu.org; Mon, 08 Feb 2010 09:49:25 -0500 Received: by gxk23 with SMTP id 23so15259gxk.2 for ; Mon, 08 Feb 2010 06:49:23 -0800 (PST) Message-ID: <4B702470.5080401@codemonkey.ws> Date: Mon, 08 Feb 2010 08:49:20 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Two QMP events issues References: <20100208114145.4bd64349@doriath> <20100208141218.GG17328@redhat.com> In-Reply-To: <20100208141218.GG17328@redhat.com> 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: "Daniel P. Berrange" Cc: armbru@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 02/08/2010 08:12 AM, Daniel P. Berrange wrote: > > For further backgrou, the key end goal here is that in a QMP client, upon > receipt of the 'RESET' event, we need to reliably& immediately determine > why it occurred. eg, triggered by watchdog, or by guest OS request. There > are actually 3 possible sequences > > - WATCHDOG + action=reset, followed by RESET. Assuming no intervening > event can occurr, the client can merely record 'WATCHDOG' and interpret > it when it gets the immediately following 'RESET' event > > - RESET, followed by WATCHDOG + action=reset. The client doesn't know > the reason for the RESET and can't wait arbitrarily for WATCHDOG since > there might never be one arriving. > > - RESET + source=watchdog. Client directly sees the reason > > The second scenario is the one I'd like us to avoid at all costs, since it > will require the client to introduce arbitrary delays in processing events > to determine cause. The first is slightly inconvenient, but doable if we > can assume no intervening events will occur, between WATCHDOG and the > RESET events. The last is obviously simplest for the clients. > I really prefer the third option but I'm a little concerned that we're throwing events around somewhat haphazardly. So let me ask, why does a client need to determine when a guest reset and why it reset? Regards, Anthony Liguori