From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJxXd-0001AG-2b for qemu-devel@nongnu.org; Tue, 28 Jul 2015 01:35:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJxXX-0005Ct-Ip for qemu-devel@nongnu.org; Tue, 28 Jul 2015 01:35:04 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:42734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJxXW-0005Bj-WB for qemu-devel@nongnu.org; Tue, 28 Jul 2015 01:34:59 -0400 Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 28 Jul 2015 15:34:55 +1000 Date: Tue, 28 Jul 2015 11:03:58 +0530 From: Bharata B Rao Message-ID: <20150728053358.GA7095@in.ibm.com> References: <1436954233-1959-1-git-send-email-bharata@linux.vnet.ibm.com> <20150716065501.GD4827@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150716065501.GD4827@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v0] spapr: Abort when hash table size requirement isn't met Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org, agraf@suse.de, david@gibson.dropbear.id.au Any views on this ? On Thu, Jul 16, 2015 at 12:25:01PM +0530, Bharata B Rao wrote: > On Wed, Jul 15, 2015 at 03:27:13PM +0530, Bharata B Rao wrote: > > [This patch addresses an issue which is not prominently seen in mainline, > > but seen frequently only in David's spapr-next branch. Though it is possible > > to see this issue with mainline too, the current version of the patch > > is intended for David's tree.] > > > > QEMU requests for hash table allocation through KVM_PPC_ALLOCATE_HTAB ioctl > > by providing the size hint via htab_shift value. Sometimes the hinted > > size requirement can't be met by the host and it returns with a lower > > value for htab_shift. > > > > This was fine until recently where the hash table size was dependent > > on guest RAM size. With the intention of supporting memory hotplug, hash > > table size was changed to depend on maxram size recently. Since it is > > typical to have maxram size to be much higher than RAM size, the possibility > > of host not being able to meet the size requirement has increased. This > > causes two problems: > > > > - When memory hotplug is supported, we will not be able to grow till > > maxram if the host wasn't able to satisfy the hash table size for the > > the full maxram range. > > This is a recoverable condition where the hotplug can be gracefully failed. > > > - During migration, we can end up having different htab_shift values (and > > hence different hash table sizes) at the source and target due to > > which the migration fails. > > One possible way to solve this is to change (reduce) the maxram_size > based on the negotiated value of htab_shit and use the changed value > of maxram_size at the target during migration. However AFAIK, currently > there is no way to communicate the changed maxram_size back to libvirt, > so this solution may not be feasible. > > So it is the question of whether to allow the guest to boot with reduced > hashtable size and fail migration (this is the current behaviour) > > or > > As done in this patch, prevent the booting of the VM altogether. > > I am leaning towards the former. Thoughts ? > > Regards, > Bharata.