From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTHkR-0004Jm-6f for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:31:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTHkL-0004Gg-Gg for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:31:37 -0500 Received: from [199.232.76.173] (port=39176 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTHkL-0004Gc-D7 for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:31:33 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:36770) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTHkJ-0005jX-Ii for qemu-devel@nongnu.org; Fri, 08 Jan 2010 11:31:31 -0500 Received: by yxe26 with SMTP id 26so18819837yxe.4 for ; Fri, 08 Jan 2010 08:31:31 -0800 (PST) Message-ID: <4B475DE0.9040100@codemonkey.ws> Date: Fri, 08 Jan 2010 10:31:28 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver 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> In-Reply-To: <20100107163014.47662b8c@doriath> 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: Luiz Capitulino Cc: qemu-devel , Avi Kivity , Adam Litke 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. Regards, Anthony Liguori