[coyotos-dev] GPT questions

[Jonathan S. Shapiro]

On Fri, 2007-04-27 at 16:16 -0700, Charles Landau wrote:
> 1. If my understanding is correct, in a window capability, the guard 
> and the offset are redundant. The offset is added to the virtual 
> address, and the guard is effectively subtracted.

Hmm. I need to think on that, but it sounds right. I still tend to
believe that regularizing the path is useful. One minor (and possibly
insignificant) difference is that the current specification guarantees
absence of address rollover into hibit+1, where omitting the guard would
not ensure that property.

Hmm.

> I can understand why you might want both. The offset has more bits, 
> and the logic might be simpler if you allow guards in window keys as 
> well as other memory keys that don't contain an offset.

That was the original thought. Earlier specifications only required
(offset % 2^l2v)==0. The realization that l2g could be used equally well
didn't happen until later.

> 2. At http://www.coyotos.org/docs/ukernel/spec.html#as_compose, the 
> spec says "Care should be taken to set the l2v value appropriately 
> when the ha [or bg] bit is set. " Do you mean that l2v should be >= 
> 61, so there is no possibility of using slots 14 and 15 in 
> translation (because u < 8)? Or simply that the u field of the 
> address space should be no more than 3 bits in size, which happens if 
> l2v is at least 3 + the *expected* value of l2g? In the latter case, 
> the GPT can't be sure that someone won't create a new capability to 
> the GPT with a different l2g.

We have provisionally decided to retire the 'ha' bit. Memory faults are
directed to the process fault handling logic (therefore usually to the
activation handler), which is responsible for knowing what to do.

With this change in place, I think that statement could be removed. The
idea was to suggest that a keeper might arrange to avoid unintended
traversal of the handler slot by controlling the delta between the kept
GPT l2v and the l2v of its parent. Later, we decided that bg!=0 =>
maxSlot=8.

However, with the removal of the 'ha' bit, we are reconsidering this. We
have deferred final resolution until there is an implementation in hand,
but the prevailing opinion of the week is that if 'bg' is set then
either (a) the GPT header should contain the index of the background
capability, or (b) all GPTs should just have a 17th slot.


-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC