| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[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).
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home