From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] Revert "xen-hvm: increase maxmem before calling xc_domain_populate_physmap" Date: Thu, 11 Jun 2015 11:56:23 +0100 Message-ID: <1434020183.30003.146.camel@citrix.com> References: <1433940913-19425-1-git-send-email-george.dunlap@eu.citrix.com> <557839CD.6070501@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <557839CD.6070501@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Wei Liu , Andrew Cooper , Stefano Stabellini , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Wed, 2015-06-10 at 14:21 +0100, George Dunlap wrote: > On 06/10/2015 01:55 PM, George Dunlap wrote: > > This reverts commit c1d322e6048796296555dd36fdd102d7fa2f50bf. > > > > The original commit fixes a bug when assigning a large number of > > devices which require option roms to a guest. (One known > > configuration that needs extra memory is having more than 4 emulated > > NICs assigned. Three or fewer NICs seems to work without this > > functionality.) > > > > However, by unilaterally increasing maxmem, it introduces two > > problems. > > > > First, now libxl's calculation of the required maxmem during migration > > is broken -- any guest which exercised this functionality will fail on > > migration. (Guests which have the default number of devices are not > > affected.) > > Just to make it clear what the situation is (to the best of my knowledge): > > QEMU 2.2 and before: > * A VM assigned more than 3 NICs would fail during qemu start-up > * A VM assigned 3 or fewer NICs can be created and migrated successfully. > > QEMU 2.3 (most recent release): > * A VM assigned more than 3 NICs can be created successfully, but not > migrated afterwards > * A VM assigned 3 or fewer NICs can be both created and migrated. > (Stefano has done a few tests to verify this and it seems to be accurate.) > > It's unlikely that the "proper fix" descibed in this mail will be ready > for 2.4, so if this patch is accepted, 2.4 will look like 2.2. FWIW I think reverting would be the right thing to do. I think we should also revert some of the changes to libxl which tried to cope with the qemu 2.2 behaviour. Ian.