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


[Xen-devel] Re: [PATCH v2.0 0/6] Add memory add support to Xen

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Yunhong Jiang <yunhong.jiang@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH v2.0 0/6] Add memory add support to Xen
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 10 Jul 2009 09:25:44 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 10 Jul 2009 01:26:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A5707020200007800009C02@xxxxxxxxxxxxxxxxxx>
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: AcoBLmfsBqyBAGP0TwuLO5g+HsuGcAACZyn8
Thread-topic: [PATCH v2.0 0/6] Add memory add support to Xen
User-agent: Microsoft-Entourage/
On 10/07/2009 08:16, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> There's one other problem with this overall change: Non-pv-ops pv Linux guests
> (all versions afaict) establish an upper bound on the m2p table size during
> early boot, and use this to bound check MFNs before accessing the array (see
> the setup and use of machine_to_phys_order). Hence, when you grow the m2p
> table, you might need to send some sort of notification to all pv domains so
> that they can adjust that upper bound. If not a notification, some other
> communication mechanism will be needed (i.e. a new ELF note). Hot-added memory
> must never be made visible to a pv guest not supporting this new protocol (in
> particular, hot add may need to be disabled altogether if Dom0 doesn't support
> it).

The correct answer I think is for Xen to specify a machine_to_phys order
that corresponds to the size of the M2P 'hole' rather than to the actual
amount of memory currently populated on this host. The extra inefficiency is
only that some I/O MFNs may be detected via fault rather than out-of-bounds
check (and then probably only on systems with <4G RAM).

This for x86/64 guests of course. We already established that compat guests
and memory add are going to have lesser mutual support.

 -- Keir

> As to pv-ops currently not being affected by this - the respective check
> currently sits in an #if 0 conditional, but certainly this is a latent bug
> (becoming a real one as soon as Dom0 or device pass-through come into the
> picture): Since without the check unbounded MFNs can be used to index into the
> array, it is possible to access I/O memory here, so simply being prepared to
> handle a fault resulting from an out-of-bounds access isn't enough. The
> minimally required boundary check is to make sure the resulting address is
> still inside hypervisor space (under the assumption that the hypervisor will
> itself never make I/O memory addressable for the guest).

Xen-devel mailing list