> Do you mean that (in a very simple view) Xen will take care of memory
> and domain management and another domain (domain 0?) will take care of
> every other piece of hardware like IDE, SCSI and NICs?
There'll be a concept of 'driver domains', each one of which can
take care of one or more devices. As well as running the
hardware, they'll handle the secure virtualization of the device
to domains. They only contain soft state, so if a device driver
fails it can just be re-instantiated (assuming it hasn't
managed to irrecoverably wedge the hardware or DMA all over
memory, but such faults are relatively rare...)
> This would be very cool but, as I understand. Xen requires "hardware"
> drivers to be event based, so the guest OS in domain 0 would need a
> giant patch... Right?
To enable us to use Linux drivers, the device driver domains will
be based on a cut-down version of xenolinux with all the
unnecessary stuff compiled out (most driver domains will have no
need for file systems, network stacks, character devices etc).
These domains will need additional code to do the device
virtualization, effectively moving the code that's already in Xen
into these domains.
> And Xen will end up with a) the Xen core, b) "hardware domain" guest OS
> patch and c) general guest patches. Now we have a) and c), only... :-)
Kind of, but its wrong to think of driver domains as conventional
guest OSes : nobody logs into them so there's no need to apply
Linux security patches etc. They can be a linux snapshot that's
only occasionally updated when the linux device driver model
changes.
For convenience, we'll probably maintain all the patches in the
same xenolinux tree, i.e. the arch-xeno guest patches, the
privileged domain patches, and the device virtualization
patches. It'll just be a configuration option to determine what
kind of domain gets built.
However, it's our aim to get arch-xeno and privileged domain
patches into the main-line linux tree at some point, but it
probably wouldn't be appropriate to have the device
virtualization patches there. We'll then maintain a snapshot just
for driver domains in the Xen tree.
> Making the core small is very good, but enlarging the rest - the "guest"
> universe - is not so good...
I don't think there's going to be any significant net change in
the amount of source code that we have to maintain. The driver
domains will be a bit fatter in terms of memory usage than when
the drivers were in Xen, but we're only talking about a total of
a few of MB.
Having the device drivers outside of Xen gives us a great deal of
flexibility, making it rather easier to implement things like CoW
sparse virtual disks, layer 4 firewalling, IPv6 etc.
I think the new IO architecture is going to be a significant step
forward in terms of hardware support and flexibility. Trust us ;-)
Cheers,
Ian
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home