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 machine-to-physic table and phy-to-machin

To: tgh <tianguanhua@xxxxxxxxxx>
Subject: Re: [Xen-devel] question about machine-to-physic table and phy-to-machine table
From: Daniel Stodden <stodden@xxxxxxxxxx>
Date: Fri, 23 Mar 2007 12:44:32 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 23 Mar 2007 07:38:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <460333B8.70307@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: <45F93B96.76E4.0078.0@xxxxxxxxxx> <460333B8.70307@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2007-03-23 at 09:56 +0800, tgh wrote:
> hi
>  I read the code ,there are machine-to-physic table and 
> physic-to-machine table
> there are machine address for hardward address ,physic address for 
> guestos's view hardware and virtual address ,is it right?
> 
> phy-to-machine table is a mapping for guestos's view hardware to real 
> hardward ,is it right?

right. a paravirtual guest os will recognize its existence, and perform
the table lookup itself. shadowed memory removes that need. in that
case, xen would perform the translation. that is where 'gmfn' comes into
play. so a 'gmfn' is the pfn of a guest os which doesn't account for its
page table entries being bogus ones.

might get clear from the following macro:

#define mfn_to_gmfn(_d, mfn)                            \
    ( (shadow_mode_translate(_d))                      \
      ? get_gpfn_from_mfn(mfn)                          \
      : (mfn) )

you'll see those distinctions quite regularly on the xen side.

> I am confused about the meaning and function of  machine-to-physic address

it *is* confusing, admittedly. in my understanding, one reaseon for
'm2p'/'p2m' being used is that guest operating systems, most prominently
linux, have always been using 'pfn' for 'page frame number' and the like
when referring to 'physical' memory. now you need some kind of
distinction in the paravirtual guest case, because those oses will deal
with both.

that host memory becoming a non-contiguous, non-physical one clearly
doesn't justify to substitute the names all across the kernel codebase.
equally, you could not name it virtual or similar in the vmm, because
the term 'virtual' has obviously been allocated elsewhere.

so host memory became 'machine' memory. in a different universe, it
might have rather been the actual 'physical' one. or 'host' memory.
virtual machine memory got a 'p' like in both 'pseudo-physical' and/or
'pfn' and i suppose turned for a significant number of people into
'physical' at some point. which is largely misleading.

regards,
daniel

-- 
Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B


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