On Sat, May 03, 2008 at 07:13:26PM +0100, Andrew Doran wrote:
> > DOMU kernels don't need any physical device drivers (and because of this,
> > DOMU kernels build much faster than dom0 kernels). There's an issue
> > with XPMAP_OFFSET being different in some cases.
> > It should be possible to have a kernel that can work both dom0 and domU
> > for Xen >= 3.1
>
> I will try a few experiments but it will be a while before I have the time.
> I'm also interested in the possibility of using multiboot to pass a root
> disk image or module to the DOMU kernels for installs.
I'm not sure how Xen actually deal with that for domUs. I don't think it's
multiboot (but it may be close to multiboot).
>
> > but that would make a heavily-bloated domU kernel.
> > I'd prefer to keep separate domU kernels, with only the needed code for
> > domU operations (A Xen3 dom0 kernel is 9.5MiB, a domU kernel is less
> > than 4MiB).
>
> I think that's simply fallacious. Yes, our kernels are too fat and we are
> working on that, but you would be hard pushed today to buy a new PC off the
> shelf with less than 512MB of RAM. We're speaking of virtualization, not
> embedded systems or constrained systems that can just about support one OS.
please stop assuming we can always throw more hardware to fix software bloat.
It's just not true.
> As of now we build 2 kernels for i386, 2 kernels for amd64, and 11 kernels
> for xen. The reasons behind that are technical, it's not a big deal because
Putting numbers this way isn't fair, because under the word "Xen" there are
4 different architectures: Xen3/amd64, Xen3/i386, Xen3/i386PAE and Xen2/i386.
--
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
--