From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTI3c-0005w8-8y for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:51:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTI3X-0005sW-CY for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:51:27 -0500 Received: from [199.232.76.173] (port=34293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTI3W-0005sJ-Vk for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:51:23 -0500 Received: from mx20.gnu.org ([199.232.41.8]:11287) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NTI3W-0007ka-J1 for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:51:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTI3V-0001Iz-Po for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:51:22 -0500 Date: Fri, 8 Jan 2010 14:51:11 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver Message-ID: <20100108145111.5e8c486c@doriath> In-Reply-To: <4B475DE0.9040100@codemonkey.ws> References: <1262711318.10698.104.camel@aglitke> <4B45F9CA.7050903@codemonkey.ws> <20100107154918.GB19168@redhat.com> <1262881658.2767.12.camel@aglitke> <4B460E55.9090800@redhat.com> <4B461233.2020808@codemonkey.ws> <20100107155830.71fc3f76@doriath> <20100107163014.47662b8c@doriath> <4B475DE0.9040100@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: qemu-devel , Avi Kivity , Adam Litke On Fri, 08 Jan 2010 10:31:28 -0600 Anthony Liguori wrote: > On 01/07/2010 12:30 PM, Luiz Capitulino wrote: > > On Thu, 7 Jan 2010 15:58:30 -0200 > > Luiz Capitulino wrote: > > > > > >> I like Daniel's idea too. In practice 'refresh-balloon' is going to > >> be Anthony's idea #1 for the QMP case, which seems the right way to > >> do it with QMP. > >> > > Hm, something that has just occurred to me: it's easy to have > > async messages in the user Monitor, we could add a new type of > > user print callback called async_print. > > > > This new callback would be called by the Monitor when the async > > message API is called but we are in user mode. > > > > This is really today's user_print, but user data is printed > > asynchronously. > > > > Even if we did that, it still suffers from the problem of a malicious or > broken guest that would not respond thereby hanging the monitor. True. We could print the timeout but that's not user friendly. Btw, I don't remember if I said that already but we could send the command id with the timeout event.