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
|
Home