Re: [Xen-devel] question about machine-to-physic table and phy-to-machine table

[Daniel Stodden <stodden@xxxxxxxxxx>]

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