From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV87u-0006p9-Ol for qemu-devel@nongnu.org; Thu, 17 May 2012 17:20:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SV87s-00089B-Na for qemu-devel@nongnu.org; Thu, 17 May 2012 17:20:50 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:51786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SV87s-00088f-Ib for qemu-devel@nongnu.org; Thu, 17 May 2012 17:20:48 -0400 Received: by yenm4 with SMTP id m4so2921684yen.4 for ; Thu, 17 May 2012 14:20:46 -0700 (PDT) Message-ID: <4FB56BAA.8070409@codemonkey.ws> Date: Thu, 17 May 2012 16:20:42 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1337163047-6159-1-git-send-email-berrange@redhat.com> <20120516154245.0d9b0cec@doriath.home> <4FB3F8DA.4030809@codemonkey.ws> <20120517074944.GB24943@redhat.com> <20120517095635.4237f903@doriath.home> In-Reply-To: <20120517095635.4237f903@doriath.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Add event notification for guest balloon changes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Amit Shah , qemu-devel@nongnu.org, Markus Armbruster On 05/17/2012 07:56 AM, Luiz Capitulino wrote: > On Thu, 17 May 2012 08:49:44 +0100 > "Daniel P. Berrange" wrote: > >> On Wed, May 16, 2012 at 01:58:34PM -0500, Anthony Liguori wrote: >>> On 05/16/2012 01:42 PM, Luiz Capitulino wrote: >>>> On Wed, 16 May 2012 11:10:47 +0100 >>>> "Daniel P. Berrange" wrote: >>>> >>>>> From: "Daniel P. Berrange" >>>>> >>>>> After setting a balloon target value, applications have to >>>>> continually poll 'query-balloon' to determine whether the >>>>> guest has reacted to this request. The virtio-balloon backend >>>>> knows exactly when the guest has reacted though, and thus it >>>>> is possible to emit a JSON event to tell the mgmt application >>>>> whenever the guest balloon changes. >>>>> >>>>> This introduces a new 'qemu_balloon_change()' API which is >>>>> to be called by balloon driver backends, whenever they have >>>>> a change in balloon value. This takes the 'actual' balloon >>>>> value, as would be found in the BalloonInfo struct. >>>>> >>>>> The qemu_balloon_change API emits a JSON monitor event which >>>>> looks like: >>>>> >>>>> {"timestamp": {"seconds": 1337162462, "microseconds": 814521}, >>>>> "event": "BALLOON_CHANGE", "data": {"actual": 944766976}} >>>> >>>> It's missing an entry in QMP/qmp-events.txt and I have a comment below, >>>> but in general looks good. >>>> >>>> Amit, would be good to get your ack. >>> >>> I think it would be safer to limit this event to (1) only firing >>> once target has been reached (2) firing if target is deviated from >>> without a corresponding change in target. >>> >>> Otherwise, a guest could just flood libvirt with events. This would >>> queue memory in QEMU indefinitely as the events got queued up to >>> potentially serving as a DoS against other guests. >> >> Hmm, that's a good point, but my concern was that if we only emit >> the event when the target is reached, what happens if the guest >> gets very close to the target but never actually reaches it for >> some reason. > > Having a way to detect the last balloon change would be perfect. libvirt certainly would have to maintain a timeout and make a decision on what to do if the guest doesn't balloon to target. Not sure how having events help at all here. >> Should we perhaps just rate limit it to once per second ? >> >> BTW, if we're considering guest initiated events to be a potential >> DOS in this way, then I should point out the RTC_CHANGE event >> will already suffer this way, if a malicious guest continually >> adjusts its hardware close. So we might want to apply rate limiting >> to that event too ? > > I think several events can suffer from that. For example, a VNC > client could repeatedly connect& disconnect from QEMU. If we're going > to fix this, then we'd need a general solution for it. No, VNC clients are a whole different ballgame. VNC connections will only happen from the management network, we don't worry about memory allocation from malicious VNC clients. Regards, Anthony Liguori > But I think the balloon case is different, because we're not fighting > malicious guests/clients, it's really the balloon operation that can > cause the flood. > >