WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen1.2 NetBSD port snapshot available and set_gdt patch

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen1.2 NetBSD port snapshot available and set_gdt patch for Xen1.2
From: Christian Limpach <chris@xxxxxx>
Date: Tue, 3 Feb 2004 15:54:34 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 03 Feb 2004 15:04:01 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1AnwAj-0006zR-00@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > yes, that was neat.  I'm not happy with the hack of passing the symbol
table
> > in as an initrd but I can fix that by embedding the symbol table into
the
> > kernel image's data section.  That would also remove the dumpsym program
> > from the build step and then I can include the mangling of the kernel
into a
> > XenoGues image into the regular build.  That would also make NetBSD/xen
> > cross-buildable, i.e. you can build it on a Linux host.
>
> Would it be useful to have simnple ELF loading support in the domain
> builder? This would get rid of teh need for symtab munging and the
> cheesy XenoGues stuff when building NetBSD.

yes, although the loader will have to get the setup right:  we need an ELF
header in front of the symbol table, i.e. the layout after loading should
be:
    ...
__bss_start:
    bss space
_end:
    somewhat mangled ELF header
    STRTAB/SYMTAB sections (only the STRTAB sections which are referenced by
a SYMTAB section)
esym:

Right now the dumpsym program extracts the mangled header and the required
sections, we pass this in as an initrd and the kernel then copies the initrd
to _end and initializes esym from MOD_LEN.  This is fine except that it
needs 2 files and that's annoying.

I would add our loader to the domain builder except that it has a 4 clause
BSD licence and I don't know if you want code in Xen which has the
advertising clause.  The loader is in the NetBSD tree at
sys/lib/libsa/loadfile_elf32.c.  grub also includes a loader which sets
things up correctly...

> If/when upgrading to 1.3, please be aware of a couple of interface
> changes (there will also likely be more, as we add device-driver
> isolation and proper bidirectional console support for example):
>  1. The MMU_update interface takes a physical pointer to a PTE, not a
>  virtual address.

I think I have all/most of these in macros/functions.

>  2. The block-device and network I/O rings are now indexed using
>  non-wrapping counters. e.g. rather than
>    i = (i + 1) % RING_SIZE;
>    ent = ring[i];
>  you do
>    ent = ring[++i];
>  There are predefined index types NET_RING_IDX and BLK_RING_IDX.

That's ent = ring[MASK_NET_{R,T}X_IDX(++i)], right?
I think I'll use non-wrapping counters when writing the block-device driver
and I'll apply the mask when accessing the ring counters...

    christian



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel