[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Xen-users] rump kernels running on the Xen hypervisor

Antti Kantee writes ("Re: [Xen-users] rump kernels running on the Xen 
> So, to answer your question, applications do not need to be explicitly 
> written to use rump kernels, but all of the interfaces used by 
> applications need to of course be provided somehow.  [...]

This is all very exciting and as Ian Jackson says very similar to
something I've been working on.  I started from the other end and it
may be that I can combine what I've done so far with what you've done.

I compiled up your example, against Xen 4.4-unstable, and I'm afraid
it doesn't work for me.  Console log below.  Do you have any
suggestions for debugging it or should I just plunge in ?

Did you test this on i386 or should I rebuild as amd64 ?

I think this approach will be an excellent one for stub domains such
as qemu, proposed stub-pygrub, etc.

But thinking about what you've done, I think we probably want to do
something a bit different with block and networking.

Does the NetBSD VFS have
 - tmpfs on variable-sized ramdisk
 - romfs based on a cpio archive
or the like ?  Producing an ffs image for something like a qemu-dm is
going to be annoying.

And often networking wants to be handled by something like SOCKS
rather than by having an extra TCP stack in the stub domain.  The
reason for this is that it avoids having to allocate MAC and IP
addresses to a whole bunch of service domains; the administrator
probably wants them to piggyback on dom0's networking.


Xen Minimal OS!
  start_info: 001fa000(VA)
    nr_pages: 0x800
  shared_inf: 0x7f03e000(MA)
     pt_base: 001fd000(VA)
nr_pt_frames: 0x5
    mfn_list: 001f8000(VA)
   mod_start: 0x0(VA)
     mod_len: 0
       flags: 0x0
    cmd_line: 3
  stack:      001d2240-001f2240
MM: Init
      _text: 00000000(VA)
     _etext: 0016df32(VA)
   _erodata: 00199000(VA)
     _edata: 0019ddbc(VA)
stack start: 001d2240(VA)
       _end: 001f73f8(VA)
  start_pfn: 205
    max_pfn: 800
Mapping memory range 0x400000 - 0x800000
setting 00000000-00199000 readonly
skipped 00001000
MM: Initialise page allocator for 207000(207000)-0(800000)
MM: done
Demand map pfns at 801000-80801000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 00801000.
Initialising scheduler
xenbus initialised on irq 1 mfn 0x60cb1
Dummy main: start_info=001f3180
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 6.99.23 (RUMP-ROAST) #0: Tue Aug 20 18:33:04 BST 2013
total memory = unlimited (host limit)
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "rumpclk" frequency 100 Hz quality 0
cpu0 at thinair0: rump virtual cpu
root file system type: rumpfs
******************* BLKFRONT for device/vbd/768 **********

Page fault at linear address c2c2c36a, eip 0016961c, regs 0024ff04, sp 
c2c2c2c2, our_sp 0024fee8, code 0
Thread: biopoll
EIP: 16961c, EFLAGS 10212.
EBX: c2c2c2c2 ECX: 0020c0bc EDX: 0020c138
ESI: 00000000 EDI: 0000001a EBP: 0024ff80 EAX: c2c2c2c2
DS: c2c2e021 ES: e021 orig_eax: ffffffff, eip: 0016961c
CS: e019 EFLAGS: 00010212 esp: c2c2c2c2 ss: c2c2c2c2
base is 0x24ff80 caller is 0x169819
base is 0x24ffa0 caller is 0x169a0a
base is 0x24ffc0 caller is 0xfbf2
base is 0x24fff0 caller is 0x31ad

c2c2c2b0:Page fault in pagetable walk (access to invalid memory?).

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.