Mailing List Archive

> On Wed, Jun 15, 2005 at 02:35:39PM +0100, Mark Williamson wrote:
> > filesystems Linux will support. *however* this will arguably be most
> > important to people who are a) paranoid about security (highly untrusted
> > guests) or b) use really weird filesystems ;-)
>
> Well, "weird" may mean anything; Given that the UFS of linux is nicely said
> "dark", and Xen is not a linux-only thing anymore (see *BSD).

True :-)

By "weird filesystems" I really meant that this bootloader approach will
support any guest filesystem that Linux can support. This includes the
commonly used Linux filesystems (ext and ReiserFS), high performance
filesystems like XFS and Reiser4, and also more unusual things like BeFS.

Adding support to the dom0-based loader shouldn't be *that* hard but does
require explicit use of a new filesystem library. Also, I doubt that all
FSes supported by Linux have such a library available...

I don't know much about Linux's UFS support. However, if it's able to mount
UFS read-only that'd be enough. Can it do this reliably?

> Speaking of it, as there are several Operating Systems out there which
> want to act as a domO-able OS, too - How "portable" do you think Xen is?

Xen itself shouldn't need to be modified at all for this - guests need to be
ported to use the dom0 and privileged interfaces, which are OS independent...

The major work is in modifying the OS to run on Xen using these interfaces and
in writing "backend" drivers so that it can support unprivileged domains.

> Furthermore, Not all xentools are written in python, right? One could
> count taht as a bug.

There are a few shell scripts, yes. Also, the lowlevel code is in C for
performance and convenience reasons.

Porting an OS to run as dom0 is going to be much harder than fixing the tools
to work under that OS. For UNIX-likes, fixing the tools isn't hard, as you
say (they work on NetBSD as well as Linux, presumably with a few tweaks). A
Windows (or Mac OS Xi, for that matter) dom0 is still quite far off.

> I'd love a world where I could boot and run all BSDs, some linuxes, Plan9,
> some other Operating Systems (currently no xen support at all ;) ). So that
> needs a bit more than some shell-script that will just run on unix; Even
> Python may be complicated, but is way better than sticking to #!/bin/sh.

Well, for unpriv guests you'll be able to do that anyhow. It's just dom0 that
needs to be running all this stuff. The issues you've described will
definitely be very relevant if / when we start running non UNIX-like dom0s
but I don't think that'll happen for quite a long time.

Cheers,
Mark

>
> > Cheers,
> > Mark
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Jun 15, 2005 at 03:36:16PM +0100, Mark Williamson wrote:
> By "weird filesystems" I really meant that this bootloader approach will
> support any guest filesystem that Linux can support. This includes the

"Linux": No.. the library of the program you mentioned, pyGrub. Right?


> Adding support to the dom0-based loader shouldn't be *that* hard but does
> require explicit use of a new filesystem library. Also, I doubt that all
> FSes supported by Linux have such a library available...
>

Isn't that just bloat? What is actually "hard" to just boot the first
sector of the filesystem, wihtout knowing nothing about it at all?

We can assume that there was the OS installation procedure that installed
a bootloader to load everything appropiatly. Like you install the OS
nativly. Just that you make the bootloader boot a domU kernel, and thats
all.

> I don't know much about Linux's UFS support. However, if it's able to mount
> UFS read-only that'd be enough. Can it do this reliably?

Well "reliably" ;) .. I mounted UFSs RO in the past, But I rather mount ext2
from any BSD ;)

>
> > Speaking of it, as there are several Operating Systems out there which
> > want to act as a domO-able OS, too - How "portable" do you think Xen is?
>
> Xen itself shouldn't need to be modified at all for this - guests need to be
> ported to use the dom0 and privileged interfaces, which are OS independent...

Eh, sorry I misused terminology. I meant the user-space tools needed
by the dom0 to control the other domains, so the "frontend" (I like that
term :) ).

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> > By "weird filesystems" I really meant that this bootloader approach will
> > support any guest filesystem that Linux can support. This includes the
>
> "Linux": No.. the library of the program you mentioned, pyGrub. Right?

The PyGrub approach runs the bootloader in dom0 using filesystem libraries.
The kexec-based approach runs the bootloader in the domU you are starting, as
an application.

> > Adding support to the dom0-based loader shouldn't be *that* hard but does
> > require explicit use of a new filesystem library. Also, I doubt that all
> > FSes supported by Linux have such a library available...
>
> Isn't that just bloat? What is actually "hard" to just boot the first
> sector of the filesystem, wihtout knowing nothing about it at all?

The hard bit is writing a bootloader that'll do that: you can't run real Grub
in a guest because it expects to run on bare x86 hardware. This means we'd
need to write a Xen-aware port of Grub (or your favourite bootloader) *and*
that port would have to include support for each filesystem you might use.

The most straightforward approach is to run the bootloader app in dom0 and use
existing filesystem libraries to access the guest filesystem (as is currently
done). The "second most" straightforward approach is to boot Linux in the
guest, then have that load the "real" guest kernel and execute it.

> > I don't know much about Linux's UFS support. However, if it's able to
> > mount UFS read-only that'd be enough. Can it do this reliably?
>
> Well "reliably" ;) .. I mounted UFSs RO in the past, But I rather mount
> ext2 from any BSD ;)

As long as we can grab a kernel out of it that's good enough. It'd be nice if
Linux supported UFS better than it does - I'm surprised the support isn't
more advanced, actually.

> > > Speaking of it, as there are several Operating Systems out there which
> > > want to act as a domO-able OS, too - How "portable" do you think Xen
> > > is?
> >
> > Xen itself shouldn't need to be modified at all for this - guests need to
> > be ported to use the dom0 and privileged interfaces, which are OS
> > independent...
>
> Eh, sorry I misused terminology. I meant the user-space tools needed
> by the dom0 to control the other domains, so the "frontend" (I like that
> term :) ).

Sure, just meant that you can already run lots of things as a guest.
"frontend" is the driver used by the guest. "backend" is the driver that
provides virtual devices. "privileged interface" support is needed to run
the whole machine. To run as a guest, you just need frontend drivers.

Anyhow, we're a long way from running Xend in a Windows dom0 but I don't think
there's that much of the code that's UNIX specific.

Cheers,
Mark

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users