← Back to branch summary

~ubuntu-branches/ubuntu/utopic/xen/utopic

« back to all changes in this revision

Viewing changes to TODO

  • Committer: Bazaar Package Importer
  • Author(s): Bastian Blank
  • Date: 2010-05-06 15:47:38 UTC
  • mto: (1.3.1) (15.1.1 sid) (4.1.1 experimental)
  • mto: This revision was merged to the branch mainline in revision 3.
  • Revision ID: james.westby@ubuntu.com-20100506154738-agoz0rlafrh1fnq7
Tags: upstream-4.0.0
Import upstream version 4.0.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
TODO
1
 
 
2
 
 
3
 
Known limitations and work in progress
4
 
======================================
5
 
 
6
 
The current Xen Virtual Firewall Router (VFR) implementation in the
7
 
snapshot tree is very rudimentary, and in particular, lacks the RSIP
8
 
IP port-space sharing across domains that provides a better
9
 
alternative to NAT.  There's a complete new implementation under
10
 
development which also supports much better logging and auditing
11
 
support. For now, if you want NAT, see the xen_nat_enable scripts and
12
 
get domain0 to do it for you.
13
 
 
14
 
There are also a number of memory management enhancements that didn't
15
 
make this release: We have plans for a "universal buffer cache" that
16
 
enables otherwise unused system memory to be used by domains in a
17
 
read-only fashion. We also have plans for inter-domain shared-memory
18
 
to enable high-performance bulk transport for cases where the usual
19
 
internal networking performance isn't good enough (e.g. communication
20
 
with a internal file server on another domain).
21
 
 
22
 
We have the equivalent of balloon driver functionality to control
23
 
domain's memory usage, enabling a domain to give back unused pages to
24
 
Xen. This needs properly documenting, and perhaps a way of domain0
25
 
signalling to a domain that it requires it to reduce its memory
26
 
footprint, rather than just the domain volunteering (see section on
27
 
the improved control interface).
28
 
 
29
 
The current disk scheduler is rather simplistic (batch round robin),
30
 
and could be replaced by e.g. Cello if we have QoS isolation
31
 
problems. For most things it seems to work OK, but there's currently
32
 
no service differentiation or weighting.
33
 
 
34
 
Currently, although Xen runs on SMP and SMT (hyperthreaded) machines,
35
 
the scheduling is far from smart -- domains are currently statically
36
 
assigned to a CPU when they are created (in a round robin fashion).
37
 
The scheduler needs to be modified such that before going idle a
38
 
logical CPU looks for work on other run queues (particularly on the
39
 
same physical CPU). 
40
 
 
41
 
Xen currently only supports uniprocessor guest OSes. We have designed
42
 
the Xen interface with MP guests in mind, and plan to build an MP
43
 
Linux guest in due course. Basically, an MP guest would consist of
44
 
multiple scheduling domains (one per CPU) sharing a single memory
45
 
protection domain. The only extra complexity for the Xen VM system is
46
 
ensuring that when a page transitions from holding a page table or
47
 
page directory to a write-able page, we must ensure that no other CPU
48
 
still has the page in its TLB to ensure memory system integrity.  One
49
 
other issue for supporting MP guests is that we'll need some sort of
50
 
CPU gang scheduler, which will require some research.
51
 
 
52
 
Currently, the privileged domain0 can request access to the underlying
53
 
hardware. This is how we enable the VGA console and Xserver to run in
54
 
domain0. We are planning on extending this functionality to enable
55
 
other device drivers for 'low performance' devices to be run in
56
 
domain0, and then virtualized to other domains by domain0. This will
57
 
enable random PCMCIA and USB devices to be used that we're unlikely to
58
 
ever get around to writing a Xen driver for.
59
 
 
60
 
We'd also like to experiment moving the network and block device
61
 
drivers out of Xen, and each into their own special domains that are
62
 
given access to the specific set of h/w resources they need to
63
 
operate.  This will provide some isolation against faulty device
64
 
drivers, potentially allowing them to be restarted on failure. There
65
 
may be more context switches incurred, but due to Xen's pipelined
66
 
asynchronous i/o interface we expect this overhead to be amortised.
67
 
This architecture would also allow device drivers to be easily
68
 
upgraded independent of Xen, which is necessary for our vision of Xen
69
 
as a next-gen BIOS replacement.