Re: bouyer-xenamd64 merged

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Friday 23 November 2007 09:53:42 Christoph Egger wrote:
> On Thursday 22 November 2007 22:56:52 Manuel Bouyer wrote:
> > Hi,
> > as you may have noticed, I've merged the bouyer-xenamd64 to HEAD.
>
> Yes, I saw your commits. Great work!
>
> > The next NetBSD-daily builds should include amd64 Xen kernels; I've also
> > put my own build at ftp://asim.lip6.fr/outgoing/bouyer/rel/
> >
> > The system is stable enough to build kernel and packages on a dom0, or
> > a domU running on a linux or NetBSD dom0, on a 3.1.0 hypervisor.
> > The only known bug is a panic when dhclient exits in the INSTALL kernel.
> > I'm sure other bugs will show up :)
>
> IMO, the code needs a lot of cleanup. Personally I don't like the tons of
>
> #ifdef XEN
> ...
> #else
> ...
> #endif
>
> blocks. A few of them are ok, but they are too numerous now.
>
> BTW: Do you mind to remove the advertisement clause in your license test,
> please?
>
> > I've also fixed the xentools3 and xenkernel3 packages to build on amd64,
> > so installing a NetBSD dom0 is amost the same as on i386. The difficulty
> > comes from grub, which is definitively not 64bit-friendly (there are
> > 32bits inline assembly all over the place, cast from pointers to int, etc
> > ...) I've been able to get it running using the i386 3.1 binary package
> > and compat-netbsd32-3.1.
>
> hmm... If you had tried out Xen-unstable, then you would have noticed I
> already did that work. So you did double work... Pity.
>
> Xen-unstable is in stabilization phase until Xen 3.2 is out. JFYI.
>
> > Also, xentools3-hvm doens't build yet.
>
> Of course not! It won't until it is possible to build NetBSD/i386 binaries
> on NetBSD/amd64 almost by passing -m32 to gcc. The problem is not gcc here,
> it is the lack of i386 headers and libs on NetBSD/amd64.
>
> I think, I am mentioning this the third or fourth time on this list. Did
> someone count? ;-)
>
> > For now, the symbol table is not properly loaded neither in dom0 or domU;
> > so ddb will only show the addresses and no function names. Better keep
> > around netbsd.gdb and the source tree if you want to debug it :)
>
> This is a bug in NetBSD/Xen, not in Xen. You need to pass "BSDSYMTAB=yes"
> and not "BSDSYMTAB"  in locore.S.

s/BSDSYMTAB/BSD_SYMTAB/

Sorry for the typo. What you basically need to apply is this:

Index: arch/amd64/amd64/locore.S
===================================================================
RCS file: /cvsroot/src/sys/arch/amd64/amd64/locore.S,v
retrieving revision 1.27.2.5
diff -u -p -r1.27.2.5 locore.S
--- arch/amd64/amd64/locore.S   16 Nov 2007 17:18:00 -0000      1.27.2.5
+++ arch/amd64/amd64/locore.S   23 Nov 2007 09:03:38 -0000
@@ -213,7 +213,7 @@
        .ascii  ",VIRT_ENTRY=0xffffffff80100000"
        .ascii  ",HYPERCALL_PAGE=0x00000101" /*  (???
+HYPERCALL_PAGE_OFFSET)/PAGE_SIZE) */
 #if NKSYMS > 0 || defined(DDB) || defined(LKM)
-       .ascii  ",BSD_SYMTAB"
+       .ascii  ",BSD_SYMTAB=yes"
 #endif
        .byte   0
 
And analogous the same in arch/xen/i386/locore.S