[eros-arch] Problem with the semantics of address translation and keeper invocation

[Norman Hardy]

On Sep 2, 2005, at 1:38 PM, Eric Northup wrote:

> An issue with the EROS/CapROS address translation was discovered by
> Scott Doerrie and Jonathan Shapiro while Scott was working on
> formalizing the semantics of address translation in EROS/Coyotos.
>
> summary of the kernel page fault path:
> In response to a page fault, the kernel walks the address space rooted
> in the object named by the faulting Domain's address space root key,
> walking along the path specified by the faulting virtual address.   
> If a
> Page capability is not reached in some bounded number of steps or  
> if no
> valid translation exists along the path, then a keeper will be  
> invoked.
> If a Page capability is found, the page tables are updated and the
> faulting Domain is re-started.  The kernel shares page tables whenever
> possible*, so the page table update might just re-use an existing page
> table which was already constructed, caching some Node or Page in the
> path.
>
> The problem:
> when installing page table entries, the only path whose length is
> checked is the length of the path starting at the address space  
> root of
> the faulting Domain.  A successful translation will be cached in a
> hardware page table -- a table which might be used in another hardware
> path caching another software path (whose length was not checked  
> before
> installing the page table entry).
....

Keykos had another fix to this problem, with some advantages and  
disadvantages.
I quote from <http://www.agorics.com/Library/KeyKos/Gnosis/28.html>.
We divide the access path into three parts. The first part is from  
the beginning through the first key with ssc < 6. The second part is  
from there through the first key with ssc < 4. The third part is the  
rest.
The number of keys in a part may not be more than 20, otherwise the  
result is an error with code 6.

The numbers 4 and 6 depend on the machine architecture which  
determines opportunities to share mapping tables.
(4 and 6 were for the 370)
This architecture is unfortunate in that it is an awkward machine  
dependency.
It was easy to implement.

The reason we took this approach was for ease of implementation as we  
had not foreseen the communication channel.
Perhaps the architecture should merely say for some fixed n that  
"there is a limit of at least n levels on each portion".