WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC] design/API for plugging tmem into existing xen phy

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] design/API for plugging tmem into existing xen physical memory management code
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sat, 14 Feb 2009 07:41:50 +0000
Cc:
Delivery-date: Fri, 13 Feb 2009 23:42:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8d8b30af-0e70-40fb-9693-a6cd1b5ad3eb@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmOKl/zGhrvXKgGThO+IbeZX8T1SAATVJS5
Thread-topic: [Xen-devel] [RFC] design/API for plugging tmem into existing xen physical memory management code
User-agent: Microsoft-Entourage/12.15.0.081119
On 13/02/2009 22:26, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> 4) Does anybody have a list of alloc requests of
>      order > 0

Domain and vcpu structs are order 1. Shadow pages are allocated in order-2
blocks.

> ** tmem has been working for months but the code has
> until now allocated (and freed) to (and from)
> xenheap and domheap.  This has been a security hole
> as the pages were released unscrubbed and so data
> could easily leak between domains.  Obviously this
> needed to be fixed :-)  And scrubbing data at every
> transfer from tmem to domheap/xenheap would be a huge
> waste of CPU cycles, especially since the most likely
> next consumer of that same page is tmem again.

Then why not mark pages as coming from tmem when you free them, and scrub
them on next use if it isn't going back to tmem?

I wasn't clear on who would call your C and D functions, and why they can't
be merged. I might veto those depending on how ugly and exposed the changes
are outside tmem.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel