view TODO @ 875:ad4db8b417c1

bitkeeper revision 1.547 (3fa3dd2aH8eamu3ONvYovJgq8wBNbQ)

Many files:
Fixes to the DOM0 interface and domain building code. Ready for new save/restore dom0_ops.
date Sat Nov 01 16:19:54 2003 +0000 (2003-11-01)
parents 522d23c14a4f
children 6ec887aa9d16
line source
3 Known limitations and work in progress
4 ======================================
6 The "xenctl" tool used for controling domains is still rather clunky
7 and not very user friendly. In particular, it should have an option to
8 create and start a domain with all the necessary parameters set from a
9 named xml file. Update: the 'xenctl script' functionality combined
10 with the '-i' option to 'domain new' sort of does this.
12 The java xenctl tool is really just a frontend for a bunch of C tools
13 named xi_* that do the actual work of talking to Xen and setting stuff
14 up. Some local users prefer to drive the xi_ tools directly, typically
15 from simple shell scripts. These tools are even less user friendly
16 than xenctl but its arguably clearer what's going on.
18 There's also a nice web based interface for controlling domains that
19 uses apache/tomcat. Unfortunately, this has fallen out of sync with
20 respect to the underlying tools, so is currently not built by default
21 and needs fixing. It shouldn't be hard to bring it up to date.
23 The current Xen Virtual Firewall Router (VFR) implementation in the
24 snapshot tree is very rudimentary, and in particular, lacks the RSIP
25 IP port-space sharing across domains that provides a better
26 alternative to NAT. There's a complete new implementation under
27 development which also supports much better logging and auditing
28 support. For now, if you want NAT, see the xen_nat_enable scripts and
29 get domain0 to do it for you.
31 The current network scheduler is just simple round-robin between
32 domains, without any rate limiting or rate guarantees. Dropping in a
33 new scheduler is straightforward, and is planned as part of the
34 VFRv2 work package.
36 Another area that needs further work is the interface between Xen and
37 domain0 user space where the various XenoServer control daemons run.
38 The current interface is somewhat ad-hoc, making use of various
39 /proc/xeno entries that take a random assortment of arguments. We
40 intend to reimplement this to provide a consistent means of feeding
41 back accounting and logging information to the control daemon, and
42 enabling control instructions to be sent the other way (e.g. domain 3:
43 reduce your memory footprint to 10000 pages. You have 1s to comply.)
44 We should also use the same interface to provide domains with a
45 read/write virtual console interface. The current implemenation is
46 output only, though domain0 can use the VGA console read/write.
48 There's also a number of memory management hacks that didn't make this
49 release: We have plans for a "universal buffer cache" that enables
50 otherwise unused system memory to be used by domains in a read-only
51 fashion. We also have plans for inter-domain shared-memory to enable
52 high-performance bulk transport for cases where the usual internal
53 networking performance isn't good enough (e.g. communication with a
54 internal file server on another domain).
56 We also have plans to implement domain suspend/resume-to-file. This is
57 basically an extension to the current domain building process to
58 enable domain0 to read out all of the domain's state and store it in a
59 file. There are complications here due to Xen's para-virtualised
60 design, whereby since the physical machine memory pages available to
61 the guest OS are likely to be different when the OS is resumed, we
62 need to re-write the page tables appropriately.
64 We have the equivalent of balloon driver functionality to control
65 domain's memory usage, enabling a domain to give back unused pages to
66 Xen. This needs properly documenting, and perhaps a way of domain0
67 signalling to a domain that it requires it to reduce its memory
68 footprint, rather than just the domain volunteering (see section on
69 the improved control interface).
71 The current disk scheduler is rather simplistic (batch round robin),
72 and could be replaced by e.g. Cello if we have QoS isolation
73 problems. For most things it seems to work OK, but there's currently
74 no service differentiation or weighting.
76 Currently, although Xen runs on SMP and SMT (hyperthreaded) machines,
77 the scheduling is far from smart -- domains are currently statically
78 assigned to a CPU when they are created (in a round robin fashion).
79 The scheduler needs to be modified such that before going idle a
80 logical CPU looks for work on other run queues (particularly on the
81 same physical CPU).
83 Xen currently only supports uniprocessor guest OSes. We have designed
84 the Xen interface with MP guests in mind, and plan to build an MP
85 Linux guest in due course. Basically, an MP guest would consist of
86 multiple scheduling domains (one per CPU) sharing a single memory
87 protection domain. The only extra complexity for the Xen VM system is
88 ensuring that when a page transitions from holding a page table or
89 page directory to a write-able page, we must ensure that no other CPU
90 still has the page in its TLB to ensure memory system integrity. One
91 other issue for supporting MP guests is that we'll need some sort of
92 CPU gang scheduler, which will require some research.
94 Currently, the privileged domain0 can request access to the underlying
95 hardware. This is how we enable the VGA console and Xserver to run in
96 domain0. We are planning on extending this functionality to enable
97 other device drivers for 'low performance' devices to be run in
98 domain0, and then virtualized to other domains by domain0. This will
99 enable random PCMCIA and USB devices to be used that we're unlikely to
100 ever get around to writing a Xen driver for.
102 We'd also like to experiment moving the network and block device
103 drivers out of Xen, and each into their own special domains that are
104 given access to the specific set of h/w resources they need to
105 operate. This will provide some isolation against faulty device
106 drivers, potentially allowing them to be restarted on failure. There
107 may be more context switches incurred, but due to Xen's pipelined
108 asynchronous i/o interface we expect this overhead to be amortised.
109 This architecture would also allow device drivers to be easily
110 upgraded independent of Xen, which is necessary for our vision of Xen
111 as a next-gen BIOS replacement.