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].