15 messages in com.xensource.lists.xen-ia64-develRe: [Xen-ia64-devel] [RFC] grant tabl...
FromSent OnAttachments
Tian, Kevin27 Mar 2006 23:23 
Tian, Kevin27 Mar 2006 23:32 
Isaku Yamahata28 Mar 2006 01:49 
Tian, Kevin28 Mar 2006 03:45 
Isaku Yamahata28 Mar 2006 04:26 
Tian, Kevin28 Mar 2006 05:03 
Tristan Gingold26 Apr 2006 04:44 
Isaku Yamahata26 Apr 2006 19:31 
Tristan Gingold27 Apr 2006 00:34 
Isaku Yamahata27 Apr 2006 01:40 
Tristan Gingold27 Apr 2006 02:19 
Isaku Yamahata27 Apr 2006 03:10 
Tristan Gingold27 Apr 2006 04:01 
Isaku Yamahata27 Apr 2006 04:18 
Tristan Gingold27 Apr 2006 04:34 
Subject:Re: [Xen-ia64-devel] [RFC] grant table API clean up and performancetuning memo
From:Tristan Gingold (Tris@bull.net)
Date:04/27/2006 02:19:41 AM
List:com.xensource.lists.xen-ia64-devel

Le Jeudi 27 Avril 2006 10:40, Isaku Yamahata a écrit :

On Thu, Apr 27, 2006 at 09:34:54AM +0200, Tristan Gingold wrote:

Le Jeudi 27 Avril 2006 04:31, Isaku Yamahata a écrit : [...]

Two questions: It seems your mechanism still need to trust the domains. So we need to add checks for itc/ptc.

However, can a granted page be mapped several times ? If so, tracking is necessary and has a cost.

Grant table API allows it. Xen tracks it by the counter(act->pin). However current xenLinux maps one-time per a granted page, I believe.

Even if it is mapped only once in guest physical memory, it may still be mapped many times in virtual memory. True ?

Yes, it's true. Usually only __va()'ed address is used.

That's certainly true for vbd. For vnif, if the buffer is allocated from the slab, it may then be wrong. For balloon, this is not true.

I am trying to understand what can be done to avoid global vtlb flush.

Tracking tlb insert is a possible solution, but has an high cost.

Enforcing one insert policy is an easier solution: each page granted may only be mapped once in virtual memory. But this doesn't work for transfer.

I also suppose ballooning is not very frequent and thus global vtlb flush can be used when page are removed. Is it correct ?

Tristan.

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