
This is stuff we probably want to implement in the near future. I
think I have them in a sensible priority order -- the first few would
be nice to fix before a code release. The later ones can be
longer-term goals.

 -- Keir (16/3/03)


1. ACCURATE TIMERS AND WALL-CLOCK TIME
--------------------------------------
Currently our long-term timebase free runs on CPU0, with no external
calibration. We should run ntpd on domain 0 and allow this to warp
Xen's timebase. Once this is done, we can have a timebase per CPU and
not worry about relative drift (since they'll all get sync'ed
periodically by ntp).

2. ASSIGNING DOMAINS TO PROCESSORS
----------------------------------
More intelligent assignment of domains to processors. In
particular, we don't play well with hyperthreading: we will assign
domains to virtual processors on the same package, rather then
spreading them across processor packages.

What we need to do is port code from Linux which stores information on
relationships between processors in the system (eg. which ones are
siblings in the same package). We then use this to balance domains
across packages, and across virtual processors within a package.

3. DOMAIN 0 MANAGEMENT DAEMON
-----------------------------
A better control daemon is required for domain 0, which keeps proper
track of machine resources and can make sensible policy choices. This
may require support in Xen; for example, notifications (eg. DOMn is
killed), and requests (eg. can DOMn allocate x frames of memory?).

4. SANE NETWORK ROUTING
-----------------------
The current virtual firewall/router is completely broken. Needs a new
design and implementation!

5. NETWORK CHECKSUM OFFLOAD 
--------------------------- 
All the NICs that we support can checksum packets on behalf of guest
OSes. We need to add appropriate flags to and from each domain to
indicate, on transmit, which packets need the checksum added and, on
receive, which packets have been checked out as okay. We can steal
Linux's interface, which is entirely sane given NIC limitations.

6. MODULE SUPPORT FOR XEN
-------------------------
Network and blkdev drivers are bloating Xen. At some point we want to
build drivers as modules, stick them in a cheesy ramfs, then relocate
them one by one at boot time. If a driver duccessfully probes hardware
we keep it, otherwise we blow it away. Alternative is to have a
central PCI ID to driver name repository. We then use that to decide
which drivers to load.

Most of the hard stuff (relocating and the like) is done for us by
Linux's module system.

7. NEW DESIGN FEATURES
----------------------
This includes the last-chance page cache, and the unified buffer cache.



Graveyard
*********

The hypervisor page cache
-------------------------
This will allow guest OSes to make use of spare pages in the system, but
allow them to be immediately used for any new domains or memory requests.
The idea is that, when a page is laundered and falls off Linux's clean_LRU
list, rather than freeing it it becomes a candidate for passing down into
the hypervisor. In return, xeno-linux may ask for one of its previously-
cached pages back:
 (page, new_id) = cache_query(page, old_id);
If the requested page couldn't be kept, a blank page is returned.
When would Linux make the query? Whenever it wants a page back without
the delay or going to disc. Also, whenever a page would otherwise be
flushed to disc.

To try and add to the cache: (blank_page, new_id) = cache_query(page, NULL);
 [NULL means "give me a blank page"].
To try and retrieve from the cache: (page, new_id) = cache_query(x_page, id)
 [we may request that x_page just be discarded, and therefore not impinge
  on this domain's cache quota].
