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] question about the meaning of memory auto-translate and

To: tgh <tianguanhua@xxxxxxxxxx>
Subject: Re: [Xen-devel] question about the meaning of memory auto-translate and paravirtual and no pseudophysical overlay
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Sat, 07 Apr 2007 17:23:12 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 07 Apr 2007 09:22:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46145C9C.7060009@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <991B62EB36934C4EBD5B605518A724764C421E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4611C2F7.9060800@xxxxxxxxxx> <46145C9C.7060009@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> * This scheme provides consistent function and variable names even when
> * different guests are running in different memory-management modes.
> * 1. A guest running in auto-translated mode (e.g., 
> shadow_mode_translate())
> *    will have gpfn == gmfn and gmfn != mfn.
> * 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn.
> * 3. A paravirtualised guest with no pseudophysical overlay will have
> *    gpfn == gpmfn == mfn.
> *
> 
> what is the meaning about auto-translated mode,is it not the same with 
> paravirtualised one ?

An auto-translated paravirtualised guest could be Xen-aware in its
memory management code but Xen would be hiding the underlying memory
layout from it.  This is not the normal case - I'm not actually sure
it's supported these days, although it has worked in the past.

Essentially, though and autotranslated guest doesn't need to have any
awareness of the machine memory layout, it can just pretend its got all
the memory.

> does the auto-translated mode work for hvm and shadow mode? how does it 
> work?

HVM also has a version of autotranslate mode (does it have another name
for HVM?  I'm not sure...) - HVM guests always expect that they own
*all* the memory in the machine, so they need to have the real memory
layout concealed from them.  This is done by shadowing the guest's
pagetables so that a gmfn->mfn translation can be applied to them before
inserting them into the real pagetables.

> and what is the mechanism about paravirtualised guest with no 
> pseudophysical overlay?

This would be a guest that didn't use the abstraction of pseudophysical
addresses at all; it would just use virtual and (real) machine
addresses.  I'm not sure if there are any guests that operate in this
way...  Certainly the major heavyweight OSes all use this technique when
paravirtualised.

HTH,
Cheers,
Mark


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