From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLFso-0001BG-Up for qemu-devel@nongnu.org; Tue, 10 Feb 2015 13:50:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLFsk-0002Ge-Rb for qemu-devel@nongnu.org; Tue, 10 Feb 2015 13:50:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLFsk-0002GY-IP for qemu-devel@nongnu.org; Tue, 10 Feb 2015 13:49:58 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1AInvMh025304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 10 Feb 2015 13:49:57 -0500 Date: Tue, 10 Feb 2015 18:49:53 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20150210184952.GG2376@work-vm> References: <20150203170925.GK2332@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150203170925.GK2332@work-vm> Subject: Re: [Qemu-devel] balloon vs postcopy migrate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Amit Shah , aarcange@redhat.com, gal@redhat.com, Luiz Capitulino * Dr. David Alan Gilbert (dgilbert@redhat.com) wrote: > Hi, > Andrea pointed out there is a risk that a guest inflating its > balloon during a postcopy migrate could cause us problems, and > I wanted to see what the best way of avoiding the problem was. > > Guests inflating there balloon cause an madvise(MADV_DONTNEED) on > the host, marking pages as not present, that will potentially trigger > a userfault, that we are using in postcopy to detect pages that need > to be fetched from the source. > > In theory, at the moment guests *should* only ask for a balloon > inflation if they've been asked to do so by the host; however there > are no guards for that, and it's been suggested giving the > guest more freedom might be a good idea anyway. > > My alternatives seem to be: > 1) Stop servicing the message queue from the guest so > that we just don't notice the inflate messages until > afterwards. (Easy for Qemu, not sure how the guests > will like an unserviced queue). > > 2) I could keep servicing the queue and ignore the messages > (Easy for everyone, not very nice in actual used memory - > does it cause any long term problems other than that?) > > 3) I could keep servicing the queue but put the messages > in a list somewhere that replay after migrate has finished. > (That list sounds bounded only in a very large way?) As a follow up question; why is 'balloon_page' part of virtio-balloon.c rather than balloon.c ? I'm thinking of implementing (3) by putting a queue in front of balloon_page, but it seems to make more sense to put that type of thing in shared code (migration shouldn't need to know it's virtio that's the transport?) Dave > > Thoughts? > > Dave > > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK