This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume

To: Jan Beulich <JBeulich@xxxxxxxxxx>, <Ian.Campbell@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Fri, 15 Jul 2011 19:23:06 +0100
Cc: olaf@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Jul 2011 11:24:05 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=mH/kI8sy69VGdpT1d5j+wKIjQKBBE9uAlf+9d+ZMIiw=; b=VmAx8d3e6lbOdjCEPjoZBRquVSqS5s7+GQllLxE9DBAM4XJLjZHJmrx6nX/72ywYmP D4QpFJC/VpM5wT7eJH4hxDaiEzbLdqj3S6Y8wiOn9lEXnryCDOmz/bXZGBErfAYzFrPE MMhLEZ0elylKeuuX7VMHvgPFtT5Dxiw+3VLmE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E20873F020000780007307B@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxDHD2w9ppdL4DyWkqbCq16XCM1bw==
Thread-topic: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume
User-agent: Microsoft-Entourage/
On 15/07/2011 18:30, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> Actually, one more thought: What's the purpose of this hypercall if
> it is set in stone what values it ought to return? Isn't a guest using
> it (supposed to be) advertising that it can deal with the values being
> variable (and it was just overlooked so far that this doesn't only
> include varying values from boot to boot, but also migration)? Or in
> other words, if we found a need to relocate the M2P table or grow
> its static maximum size, it would be impossible to migrate guests
> from an old to a new hypervisor.

Fair point. There has to be a static fallback set of return values for old

 -- Keir

Xen-devel mailing list