Re: unmap() sometimes unmaps more pages than specified

[Joshua Haberman]
> On Nov 17, 2006, at 9:45 AM, Espen Skoglund wrote:
>> [Espen Skoglund]
>>> You have two spaces A and B.  A has a 4MB page mapping.  B has
>>> received a 4KB page mapping from A.  Currently we have:
>> 
>>> (1)  A.Flush(4K) == A.Flush(4M) since A has a 4MB mapping.
>>> (2)  Likewise A.Unmap(4K) == A.Unmap(4M) since A has a 4MB mapping.
>>> (3)  B.Flush(4K) is fine since B has a 4KB mapping.
>>> (4)  Consequently A.Unmap(4K) != B.Flush(4K).
>> 
>>> I guess (4) is what you find difficult to handle, right?  This would
>>> work fine if (2) was not the case.  Currently the implementation
>>> does (obviously) not behave this way.  I'll give some thought to how
>>> this could most easily be handled.  The behaviour also raises some
>>> questions about the semantics of resetting/reading reference bits,
>>> but I think this could possibly be sorted out.
>> 
>> FYI: Just implemented this a couple of days ago, and Jan has been
>> pushing this (and a bunch of other updates) to the public.  What we
>> have now is:  A.Unmap(4K) == B.Flush(4K).

> Does this mean that the limitation described in the second paragraph
> of section 4.1 of the reference manual no longer exists?  ("Mapped
> fpages are considered inseparable objects." ...)

> Is there a version of the reference manual available that reflects
> what is currently in CVS?


No, mapped fpages are still inseparable objects.  That is, if you
*receive* an fpage of 64K you can not assume that you can unmap an
arbitrary 4K page out of that fpage.  In practice, though, the kernel
will internally split fpages into the largest page size supported by
the architecture.  For IA32 this means that the 64K fpage will be
split into 16 * 4K, and you'll be able to unmap any of these 4K pages
as you see fit.

However, this is just an implementation artifact and may not be true
for certain kernels, i.e., the kernel may choose to cluster a number
of contigous pages together to save some overhead in the amount of
data structures needed.  Similarly, when mapping IO ports the kernel
will cluster several ports into one mapping node if possible (kind of
superpages for IO ports) to lower the amount of data structures needed
to represent the 64K IO port space.

The current reference manual *does* reflect what's currently in the
CVS.  I do agree that the text can be a bit misleading and ambigous,
and have therefore had plans for some time now to include a more
formal description of the map/grant/unmap model in an appendix.  I
even have something written up.  Just need to adapt it a bit to make
it properly fit into the manual.

	eSK