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

[Christian Limpach <chris@xxxxxx>]

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