These are some random notes on the windows that the kernel uses to access things not in its permanent address space.

A kernel window has a permanent virtual address in the kernel's space and this address is mapped to different real addresses at different times, typically just before use.

It is partly a matter of safety that most of RAM is not permanently mapped into the kernel's permant space. On some machines there may not even be enough virtual addresses to map it all in.

There are plenty of virtual addresses to have as many windows for the cost in real RAM is merely a table entry per window. We tend to allocate a distinct window for each usage even though it is likely that no more than two are really needed. It might be wise to close a window after we are done with it but we don't.

Windows are known by small integers and also by named cells in kernel memory that hold these small integers.

The routine:
uchar * map_any_window(int X, uint32 R, int rw)
changes the real address that window X refers to.
causes window X to refer to real address R.
If rw == 0 the page will be read only, and otherwise RW.
The routine returns the virtual address of the window which is a constant
function of X. Of course the TLB is flushed.

uchar * map_uncached_window(int X, uint32 R, int rw)
is like the above except that it provides an uncached access to RAM.

It is probably best to keep a particular window always cached or always uncached
as this avoids problems with cache designs yet to be invented.

The virtual addresses of the windows are contiguous and start at location vWindows.



The word "cpuargpage" holds the address of a page at CpuArgPage in the kernel's memory.
"CpuArgPage" is known to the loader and "&CpuArgPage" could be profitably substituted for "cpuargpage" throughout the kernel for improved performance at various places.

When a domain invokes a kernel object or another domain, the string argument is often placed in CpuArgPage. Various optimizations bypass CpuArgPage. Various parts of the kernel expect to find their input string argument in CpuArgPage. The part of the kernel that delivers a message to a domain often delivers the message string from CpuArgPage. It is thus natural for kernel objects to form their string responses in CpuArgPage.