Re: capability address space and virtualizing objects

[Marcus Brinkmann]

At Thu, 28 Aug 2008 18:00:18 +0200,
Neal H. Walfield wrote:
> The problem isn't extending the address translation mechanism, it's
> the ability to fully virtualize an object.  On a system like Mach,
> this is not a problem because address space construction is not
> exported to user space so there is no need to virtualize this
> functionality.
> 
> The ability to virtualize objects is useful, for instance, for
> implementing rpctrace.  If we could only virtualize non-kernel
> objects, then a program could invoke a capability in a cappage that it
> got in a message.  If rpctrace does not proxy cappages, it would not
> see any invocations on them.  The solution here might be to simply
> proxy the capabilities aggressively (i.e., proxy all reachable
> capabilities in any message).  But that can mean a lot of memory!
> Also, it would require detecting capability cycles, which is hard.

There are other options for full virtualization, as is demonstrated by
many recent virtualization platforms.  These other techniques may be a
more appropriate virtualization method in some of the use cases that
concern you than capability based virtualization.  For example, they
may offer much improved performance and may utilize hardware support
better.  In fact, those techniques are mandatory if you want full
transparent virtualization (including processor time etc).  Memory
accesses are not the only resources in a computer that need
virtualization at times (see the blue pill papers for an extreme
case).

Therefore, I find it hard to follow your reasoning that 100%
virtualizability is a worthy goal.  It is certainly an interesting
research challenge to study the semantic and implementation issues
involved, but I can't convince myself right now that programmers
actually have an incentive to make use of such properties at that
level in the Real World (tm).  If rpctrace isn't good enough, there
are heavier guns in the store.

Anyway, if you want to pursue this, I think that one approach to
understand the issues involved is to compare your situation with page
faults on either side in the L4 X.2 ipc model with regards to string
items.  There seem to be similarities.

Thanks,
Marcus