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: [RFC] transcendent memory for Linux

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC] transcendent memory for Linux
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 29 Jun 2009 14:23:38 -0700
Cc: npiggin@xxxxxxx, akpm@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, alan@xxxxxxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, kurt.hackel@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, dave.mccracken@xxxxxxxxxx, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Himanshu Raj <rhim@xxxxxxxxxxxxx>, sunil.mushran@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, Pavel Machek <pavel@xxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>, chris.mason@xxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Jul 2009 08:00:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <6639b922-4ed7-48fd-9a3d-c78a4f93355c@default>
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>
References: <6639b922-4ed7-48fd-9a3d-c78a4f93355c@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2
On 06/29/09 14:13, Dan Magenheimer wrote:
> The uuid is only used for shared pools.  If two different
> "tmem clients" (guests) agree on a 128-bit "shared secret",
> they can share a tmem pool.  For ocfs2, the 128-bit uuid in
> the on-disk superblock is used for this purpose to implement
> shared precache.  (Pages evicted by one cluster node
> can be used by another cluster node that co-resides on
> the same physical system.)

What are the implications of some third party VM guessing the "uuid" of
a shared pool?  Presumably they could view and modify the contents of
the pool.  Is there any security model beyond making UUIDs unguessable?

> The (page)size argument is always fixed (at PAGE_SIZE) for
> any given kernel.  The underlying implementation can
> be capable of supporting multiple pagesizes.

Pavel's other point was that merging the size field into the flags is a
bit unusual/ugly.  But you can workaround that by just defining the
"flag" values for each plausible page size, since there's a pretty small
bound: TMEM_PAGESZ_4K, 8K, etc.

Also, having an "API version number" is a very bad idea.  Such version
numbers are very inflexible and basically don't work (esp if you're
expecting to have multiple independent implementations of this API). 
Much better is to have feature flags; the caller asks for features on
the new pool, and pool creation either succeeds or doesn't (a call to
return the set of supported features is a good compliment).


Xen-devel mailing list