On 26 Apr 2006, at 14:21, Jan Beulich wrote:
The tables you mention above are not involved in get_mfn_from_gpfn()
--
they translate the other way.
???
xen/include/asm-x86/mm.h says:
Ah, yes, p2m table actually steals the read-only m2p memory area for
translated guests. So it's that area you're interested in (not the
RW_MPT, which really is always the m2p table).
The input gpfn either needs testing
against, or masking with, (PADDR_MASK >> PAGE_SHIFT). We should always
ensure that the m2p and p2m tables are big enough to be indexed by
that
value.
From the above header excerpt I'm getting the impression that mfn-s
are assumed to be at most 31 bits in size (bit 31
is used as an invalid indicator there). Also, in the observed case the
mfn is a 39-bit value, which is clearly inside
the range covered by (PADDR_MASK >> PAGE_SHIFT) (40 bits), however,
(RO_MPT_VIRT_END - RO_MPT_VIRT_START) covers only 38
bits (where, for the full 40-bit MFN range, 43 bits would be needed,
which would cover the entire current hypervisor
address space reservation).
Okay, maybe we need to be more restrictive: 20 bits for 32b (4GB), 22
bits for 32b-pae (16GB), and some suitable large value for 64b (31
would be fine, it's good for up to 8TB).
It'd be nice to set PADDR_BITS appropriately and use a value derived
from that, but the currently-chosen (larger) values are important for
pte checking. If we exclude bits from the pte's pfn check by making
PADDR_BITS smaller then we'll have to deal with the high-order pte bits
some other way (perhaps by folding them into the value returned by
e.g., l1e_get_flags()).
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home