Xen users - Jun 2005 - Basic Question

Hi

I''m running fedora core 4.

Whats the difference between the xenU and xen0 kernel. Is there a
technical difference, does this relate to how xen works? Can some one
please give me a little summary of how it works.

Many thanks

Shaz

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

> Whats the difference between the xenU and xen0 kernel. Is there a
> technical difference, does this relate to how xen works? Can some one
> please give me a little summary of how it works.
The xen0 kernel contains all the drivers required to run in a domU 
(unprivileged guest) *and* all the drivers required to run in dom0 (i.e. 
privileged command interface, device drivers for the real hardware, etc.).  
This''ll run in *any* domain.

The xenU kernel contains only the drivers required to run in a domU - no 
privileged command interface, no drivers for real hardware.  The only 
practical difference is that this kernel is a few hundred kilobytes smaller 
but can only run in domUs.

HTH,
Mark

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

> If I use the create a config in /etc/xen and refer to say kernel
> ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU" where do I add extra flags
> during bootup, i.e selinux=0. Do I add it to the end of this line
> like:
>
> kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU selinux=0" or do I
need
> to add to a grub.conf file in the domU?
IIRC, this sort of thing should go in the "args" variable of the
config file -
this gets appended to the kernel command line when the domain is started.

kernel= is just the path to the kernel within the dom0 ("host")
filesystem.

You don''t need a grub.conf in the guest but in the -unstable tree you
can
create one in the guest filesystem and get a bootloader prompt when you start 
the domain.  In this case, the guest kernel will need to be *inside* the 
guest filesystem for the bootloader to find it.

I''m not sure but there may be some config options required to enable
the guest
bootloader.

Cheers,
Mark
> Thanks
> Shaz
>
> On 6/15/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> > > Whats the difference between the xenU and xen0 kernel. Is there a
> > > technical difference, does this relate to how xen works? Can some
one
> > > please give me a little summary of how it works.
> >
> > The xen0 kernel contains all the drivers required to run in a domU
> > (unprivileged guest) *and* all the drivers required to run in dom0
(i.e.
> > privileged command interface, device drivers for the real hardware,
> > etc.). This''ll run in *any* domain.
> >
> > The xenU kernel contains only the drivers required to run in a domU -
no
> > privileged command interface, no drivers for real hardware.  The only
> > practical difference is that this kernel is a few hundred kilobytes
> > smaller but can only run in domUs.
> >
> > HTH,
> > Mark
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi

Thanks for the reply it was really informative.

If I use the create a config in /etc/xen and refer to say kernel
="/boot/vmlinuz-2.6.11-1.1369_FC4xenU" where do I add extra flags
during bootup, i.e selinux=0. Do I add it to the end of this line
like:

kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU selinux=0" or do I need
to add to a grub.conf file in the domU?

Thanks
Shaz

On 6/15/05, Mark Williamson <mark.williamson@cl.cam.ac.uk>
wrote:
> > Whats the difference between the xenU and xen0 kernel. Is there a
> > technical difference, does this relate to how xen works? Can some one
> > please give me a little summary of how it works.
> 
> The xen0 kernel contains all the drivers required to run in a domU
> (unprivileged guest) *and* all the drivers required to run in dom0 (i.e.
> privileged command interface, device drivers for the real hardware, etc.).
> This''ll run in *any* domain.
> 
> The xenU kernel contains only the drivers required to run in a domU - no
> privileged command interface, no drivers for real hardware.  The only
> practical difference is that this kernel is a few hundred kilobytes smaller
> but can only run in domUs.
> 
> HTH,
> Mark
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Jun 15, 2005 at 02:12:05PM +0100, Shahzad Chohan
wrote:
> Hi
> 
> Thanks for the reply it was really informative.
> 
> If I use the create a config in /etc/xen and refer to say kernel
> ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU" where do I add extra flags
> during bootup, i.e selinux=0. Do I add it to the end of this line
> like:
> 
> kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU selinux=0" or do I
need
> to add to a grub.conf file in the domU?
I think you can use the root="" directive of the xen configuration
file, e.g:
kernel="bla"
[...]
root="selinux=0 [...]"

Never did that, but that should work (as the root=-device stuff is normally
just passed as an argument to linux kernels)
> 
> Thanks
> Shaz
> 
> On 6/15/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> > > Whats the difference between the xenU and xen0 kernel. Is there a
> > > technical difference, does this relate to how xen works? Can some
one
> > > please give me a little summary of how it works.
> > 
> > The xen0 kernel contains all the drivers required to run in a domU
> > (unprivileged guest) *and* all the drivers required to run in dom0
(i.e.
> > privileged command interface, device drivers for the real hardware,
etc.).
> > This''ll run in *any* domain.
> > 
> > The xenU kernel contains only the drivers required to run in a domU -
no
> > privileged command interface, no drivers for real hardware.  The only
> > practical difference is that this kernel is a few hundred kilobytes
smaller
> > but can only run in domUs.
> > 
> > HTH,
> > 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

On Wednesday 15 June 2005 14:27, Andy Smith wrote:
> On Wed, Jun 15, 2005 at 01:11:44PM +0100, Mark Williamson wrote:
> > You don''t need a grub.conf in the guest but in the -unstable
tree you can
> > create one in the guest filesystem and get a bootloader prompt when
you
> > start the domain.  In this case, the guest kernel will need to be
> > *inside* the guest filesystem for the bootloader to find it.
> >
> > I''m not sure but there may be some config options required to
enable the
> > guest bootloader.
>
> Does the above imply that in -unstable, users can provide their own
> kernels?
Yes.  You just stick a grub.conf / menu.lst in the usual place and should Just 
Work.

We''re also working an another bootloader approach based on kexec but
the
effect will be the same.

Cheers,
Mark

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

On Wed, Jun 15, 2005 at 01:11:44PM +0100, Mark Williamson
wrote:
> You don''t need a grub.conf in the guest but in the -unstable tree
you can
> create one in the guest filesystem and get a bootloader prompt when you
start
> the domain.  In this case, the guest kernel will need to be *inside* the 
> guest filesystem for the bootloader to find it.
> 
> I''m not sure but there may be some config options required to
enable the guest
> bootloader.
Does the above imply that in -unstable, users can provide their own
kernels?


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

On Wed, Jun 15, 2005 at 02:24:26PM +0100, Mark Williamson
wrote:
> On Wednesday 15 June 2005 14:27, Andy Smith wrote:
> > Does the above imply that in -unstable, users can provide their own
> > kernels?
> 
> Yes.  You just stick a grub.conf / menu.lst in the usual place and should
Just
> Work.
>
> We''re also working an another bootloader approach based on kexec
but the
> effect will be the same.
Very nice work!  Thanks.

Out of curiosity, does this mean that the domU kernel has to exist
both inside the domU''s root file system and in the dom0 filesystem?
Or does Xen just start the bootloader from the domU filesystem and
go from there?


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

> Very nice work!  Thanks.
You should thank Jeremy Katz (RedHat) for PyGrub (aq provided some additional 
patches,  IIRC - ReiserFS support, colour support, etc).
> Out of curiosity, does this mean that the domU kernel has to exist
> both inside the domU''s root file system and in the dom0
filesystem?
> Or does Xen just start the bootloader from the domU filesystem and
> go from there?
Using PyGrub''s approach, the bootloader is part of Xend and uses a
filesystem
library to poke into the guest filesystem and read the grub.conf / menu.lst 
and the kernel, initrd, etc.  The bootloader is running in dom0 but the 
kernel only needs to be in the guest filesystem.

Using the kexec approach, there''d be a bootloader kernel in dom0 that 
initially runs in the domain, mounts the FS and finds the appropriate files.  
Kexec is then used to jump into execution of a kernel from the guest 
filesystem.  Thus the bootloader runs in the domU *and* the guest kernel is 
in the domU filesystem.

The second approach is a bit more complicated to implement (from a developer 
PoV) but does have the advantages that all access to the guest filesystem 
occurs in an unprivileged domain and that it can immediately support all 
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 ;-)

Cheers,
Mark

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

On Wed, Jun 15, 2005 at 02:24:26PM +0100, Mark Williamson
wrote:
> On Wednesday 15 June 2005 14:27, Andy Smith wrote:
> > On Wed, Jun 15, 2005 at 01:11:44PM +0100, Mark Williamson wrote:
> > > You don''t need a grub.conf in the guest but in the
-unstable tree you can
> > > create one in the guest filesystem and get a bootloader prompt
when you
> > > start the domain.  In this case, the guest kernel will need to be
> > > *inside* the guest filesystem for the bootloader to find it.
> > >
> > > I''m not sure but there may be some config options
required to enable the
> > > guest bootloader.
> >
> > Does the above imply that in -unstable, users can provide their own
> > kernels?
> 
> Yes.  You just stick a grub.conf / menu.lst in the usual place and should
Just
> Work.
Eh, maybe I did not get it completly: You mean I create a config-file using
disk = [ ''file:/...'' ]
without a kernel= command? And it boots the first sectors like the BIOS would
do?
> 
> We''re also working an another bootloader approach based on kexec
but the
> effect will be the same.
Hm can you elaborate that?
> 
> 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

> > Yes.  You just stick a grub.conf / menu.lst in the usual place and
should
> > Just Work.
>
> Eh, maybe I did not get it completly: You mean I create a config-file using
> disk = [ ''file:/...'' ]
> without a kernel= command? And it boots the first sectors like the BIOS
> would do?
To be honest I''ve not used it so I''m not exactly sure. 
Something like that
should work, but note:
a) PyGrub looks for the grub.conf / menu.lst on the first guest disk (i.e. 
first in the list).  Make sure that file exists on that device.
b) it doesn''t boot the first sectors of the disk, PyGrub is part of
Xend.
Therefore you don''t need to install a bootloader in the guest,
it''ll just
work.
> > We''re also working an another bootloader approach based on
kexec but the
> > effect will be the same.
>
> Hm can you elaborate that?
PyGrub runs as part of Xend, in dom0.  It accesses guest filesystems without 
mounting them (for security reasons) in order to parse the grub config and 
load the kernel.

Kexec allows a kernel to act as a bootloader and jump into a new kernel 
directly.  It''s slated for inclusion in Linux 2.6.13.  This approach
would
boot a special "bootloader" kernel in the guest and run the bootloader
in the
domU instead of dom0.  This is even more paranoid in security terms ;-) and 
also makes it easier to support weird filesystems in the guest.

For most people it will not matter much which approach is used.  I''m 
implementing kexec anyway because it''s a cool hack.

More details in my other post ;-)

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 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). 


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?

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

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. 
> 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

> 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

Mark Williamson wrote:
> Using the kexec approach, there''d be a bootloader kernel in dom0
that
> initially runs in the domain, mounts the FS and finds the appropriate
files.
> Kexec is then used to jump into execution of a kernel from the guest 
> filesystem.  Thus the bootloader runs in the domU *and* the guest kernel is
> in the domU filesystem.
> 
> The second approach is a bit more complicated to implement (from a
developer
> PoV) but does have the advantages that all access to the guest filesystem 
> occurs in an unprivileged domain and that it can immediately support all 
> 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 ;-)
This is very disconcerting to someone who was looking at renting out 
domU space on a Xen machine.

Will there be options to prevent a domU that booted a dom0 kernel from 
accessing xend? I''d hate for an abusive user to balloon all the other 
domUs to 16MB RAM and balloon themselves to 1GB RAM, play with 
scheduling parameters, or randomly kill off other domUs.

If this is controlled by ip/mac or other magic, please let me know and 
we''ll just forget I asked...

-- 
Andrew Thompson
http://aktzero.com/


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

> This is very disconcerting to someone who was looking at renting out
> domU space on a Xen machine.
>
> Will there be options to prevent a domU that booted a dom0 kernel from
> accessing xend? I''d hate for an abusive user to balloon all the
other
> domUs to 16MB RAM and balloon themselves to 1GB RAM, play with
> scheduling parameters, or randomly kill off other domUs.
In Xen, the guest kernel has no part in enforcing interdomain security - Xen 
does that.  Simply by running a kernel in a domU, it is unprivileged.  
Kernels running in a domU never have any special privileges unless you 
explicitly grant them from dom0.  This is unlike UML / vservers, where a 
compromise of the VM''s kernel can allow a user to "escape".

The only reason we provide a separate xenU kernel is because it''s a bit
smaller than the xen0 kernel.  The guest bootloader takes advantage of this 
support to allow users to compile their own guest kernels and select them 
themselves.

So it''s safe, don''t worry ;-)

Cheers,
Mark

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

On Wed, Jun 15, 2005 at 10:38:06AM -0400, Andrew Thompson
wrote:
> Will there be options to prevent a domU that booted a dom0 kernel from 
> accessing xend? I''d hate for an abusive user to balloon all the
other
> domUs to 16MB RAM and balloon themselves to 1GB RAM, play with 
> scheduling parameters, or randomly kill off other domUs.
If they tried to run a dom0 inside a dom0 wouldn''t they only have
access to whatever devices their domain was already allowed access
to?  SO they''d only be able to further subdivide their own RAM and
disk.. which might be interesting.


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

The "extra" parameter in the domain config file appends the specified
parameters to the kernel boot parameters. Add a line in your config file
that has:  extra="selinux=0"

Michael

On Wed, 2005-06-15 at 15:16 +0200, Sascha Retzki wrote:
> On Wed, Jun 15, 2005 at 02:12:05PM +0100, Shahzad Chohan wrote:
> > Hi
> > 
> > Thanks for the reply it was really informative.
> > 
> > If I use the create a config in /etc/xen and refer to say kernel
> > ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU" where do I add extra
flags
> > during bootup, i.e selinux=0. Do I add it to the end of this line
> > like:
> > 
> > kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xenU selinux=0" or
do I need
> > to add to a grub.conf file in the domU?
> 
> I think you can use the root="" directive of the xen
configuration file, e.g:
> kernel="bla"
> [...]
> root="selinux=0 [...]"
> 
> Never did that, but that should work (as the root=-device stuff is normally
> just passed as an argument to linux kernels)
> 
> > 
> > Thanks
> > Shaz
> > 
> > On 6/15/05, Mark Williamson <mark.williamson@cl.cam.ac.uk>
wrote:
> > > > Whats the difference between the xenU and xen0 kernel. Is
there a
> > > > technical difference, does this relate to how xen works? Can
some one
> > > > please give me a little summary of how it works.
> > > 
> > > The xen0 kernel contains all the drivers required to run in a
domU
> > > (unprivileged guest) *and* all the drivers required to run in
dom0 (i.e.
> > > privileged command interface, device drivers for the real
hardware, etc.).
> > > This''ll run in *any* domain.
> > > 
> > > The xenU kernel contains only the drivers required to run in a
domU - no
> > > privileged command interface, no drivers for real hardware.  The
only
> > > practical difference is that this kernel is a few hundred
kilobytes smaller
> > > but can only run in domUs.
> > > 
> > > HTH,
> > > 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

Mark Williamson wrote:
> In Xen, the guest kernel has no part in enforcing interdomain security - 
> Xen
> does that.  Simply by running a kernel in a domU, it is unprivileged.
> Kernels running in a domU never have any special privileges unless you
> explicitly grant them from dom0.  This is unlike UML / vservers, where a
> compromise of the VM''s kernel can allow a user to
"escape".
>
> The only reason we provide a separate xenU kernel is because it''s
a bit
> smaller than the xen0 kernel.  The guest bootloader takes advantage of 
> this
> support to allow users to compile their own guest kernels and select them
> themselves.
>
> So it''s safe, don''t worry ;-)
What about guest kernels not built with ARCH=xen? Would they just crash?

Best Regards,
Michael Paesold 


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

> > So it''s safe, don''t worry ;-)
>
> What about guest kernels not built with ARCH=xen? Would they just crash?
If using the bootloader in dom0, Xend wouldn''t even load them (since
they''d
lack the Xen ELF headers).  But assuming you did manage to get one loaded, 
it''d crash before it could even start init.

Cheers,
Mark

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

> If they tried to run a dom0 inside a dom0 wouldn''t they only have
> access to whatever devices their domain was already allowed access
> to?  SO they''d only be able to further subdivide their own RAM and
> disk.. which might be interesting.
You could certainly install multiple OSes inside your domain and dual-boot 
them.  Carving up a domain''s resources into multiple
"sub-domains" that run
simultaneously is a bit harder and will be implemented later on.

Cheers,
Mark

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