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
