From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965297Ab1GOIcm (ORCPT ); Fri, 15 Jul 2011 04:32:42 -0400 Received: from nat28.tlf.novell.com ([130.57.49.28]:63553 "EHLO nat28.tlf.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965045Ab1GOIck convert rfc822-to-8bit (ORCPT ); Fri, 15 Jul 2011 04:32:40 -0400 Message-Id: <4E201743020000780004D8B8@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 15 Jul 2011 09:32:35 +0100 From: "Jan Beulich" To: "Olaf Hering" Cc: , , , , Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume References: <4E1DB9C70200007800072DCC@nat28.tlf.novell.com> <20110714102628.GA9157@aepfle.de> In-Reply-To: <20110714102628.GA9157@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> On 14.07.11 at 12:26, Olaf Hering wrote: > On Wed, Jul 13, Jan Beulich wrote: > >> >>> Ian Campbell 07/13/11 11:12 AM >>> >> >It's not so much an objection to this patch but this issue seems to have >> >been caused by Xen cset 20892:d311d1efc25e which looks to me like a >> >subtle ABI breakage for guests. Perhaps we should introduce a feature >> >flag to indicate that a guest can cope with the m2p changing size over >> >migration like this? >> >> Indeed - migration was completely beyond my consideration when >> submitting this. A feature flag seems the right way to go to me. > > I will prepare a patch for a new feature flag. Let me fold this into the feature handling change patch I'm close to submit - without those changes I don't think a guest kernel would have a way to actually announce its capability. Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume Date: Fri, 15 Jul 2011 09:32:35 +0100 Message-ID: <4E201743020000780004D8B8@nat28.tlf.novell.com> References: <4E1DB9C70200007800072DCC@nat28.tlf.novell.com> <20110714102628.GA9157@aepfle.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20110714102628.GA9157@aepfle.de> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Olaf Hering Cc: Ian.Campbell@citrix.com, xen-devel@lists.xensource.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, keir@xen.org List-Id: xen-devel@lists.xenproject.org >>> On 14.07.11 at 12:26, Olaf Hering wrote: > On Wed, Jul 13, Jan Beulich wrote: > >> >>> Ian Campbell 07/13/11 11:12 AM >>> >> >It's not so much an objection to this patch but this issue seems to have >> >been caused by Xen cset 20892:d311d1efc25e which looks to me like a >> >subtle ABI breakage for guests. Perhaps we should introduce a feature >> >flag to indicate that a guest can cope with the m2p changing size over >> >migration like this? >> >> Indeed - migration was completely beyond my consideration when >> submitting this. A feature flag seems the right way to go to me. > > I will prepare a patch for a new feature flag. Let me fold this into the feature handling change patch I'm close to submit - without those changes I don't think a guest kernel would have a way to actually announce its capability. Jan