I''ve got xen calling into my hypervisor_callback but i''m seeing a very weird problem. On the first instruction, which is a PUSHL %eax, I take a page fault. The values of %ss and %esp on stack make no sense, and in fact change from run to run of the guest OS. All other values stay the same. PC does look right. If i just put an IRETL as the first instruction of the hypervisor_callback all is well -- no problem. Does Xen pass in a read-only stack segment to the callback? I don''t see similar problems on the Linux side. If I get a stack dump, everything EXCEPT ss/esp look fine -- cs, ds, etc. are all right. I have done a HYPERVISOR_stack_switch call, and all other interrupts work save this one. what function in Xen calls the hypervisor_callback in the guest? ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
If Xen interrupted a ring-1 activation then the hypervisor_callback stack frame will be pushed onto the stack that was interrupted. If Xen interrupted rings 2 or 3 then it uses SS:ESP specified in your call to HYPERVISOR_stack_switch when creating the hypervisor_callback stack frame. The code that creates the callback stack frame and jumps to your handler is in xen/arch/x86/entry.S -- Keir> > I''ve got xen calling into my hypervisor_callback but i''m seeing a very > weird problem. On the first instruction, which is a PUSHL %eax, I take a > page fault. The values of %ss and %esp on stack make no sense, and in > fact change from run to run of the guest OS. All other values stay the > same. PC does look right. > > If i just put an IRETL as the first instruction of the hypervisor_callback > all is well -- no problem. Does Xen pass in a read-only stack segment to > the callback? I don''t see similar problems on the Linux side. > > If I get a stack dump, everything EXCEPT ss/esp look fine -- cs, ds, etc. > are all right. > > I have done a HYPERVISOR_stack_switch call, and all other interrupts work > save this one. > > what function in Xen calls the hypervisor_callback in the guest? > > ron > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Fri, 25 Jun 2004, Keir Fraser wrote:> If Xen interrupted a ring-1 activation then the hypervisor_callback > stack frame will be pushed onto the stack that was interrupted. > > If Xen interrupted rings 2 or 3 then it uses SS:ESP specified in your > call to HYPERVISOR_stack_switch when creating the hypervisor_callback > stack frame. > > The code that creates the callback stack frame and jumps to your > handler is in xen/arch/x86/entry.Syeah, I know that code. It''s odd, but this all works fine for everything but hypervisor callbacks. Really odd. page faults and all that work fine. I''m looking at a stack dump right now, from the page fault that occurs after the failed hypervisor_callback, and i can see my wait loop CS:EIP on the stack, and the hypervisor callback address on the stack, and the page fault frame that xen built, and it has a bad SS:SP pair. The sequence is: Still in kernel, before starting up first user proc, I enable interrupts (mask = 0) and just start a wait loop, and wait to get interrupted. I do. I then take a fault, and CS:EIP is my hypervisor callback function in Plan 9, as observed from page fault stack. If I do this in hypervisor_callback function: IRETL then I never get the bogus page fault. If I do this: PUSHL AX IRETL Then I get the trap at the CS:EIP of hypervisor callback, and the SS:SP on the stack is just wrong. So it''s a guest in Ring 1, getting interrupted by Xen, callback function is activated, but callback function has an unusable ss:sp. blah. So close. ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Fri, 25 Jun 2004, ron minnich wrote:> On Fri, 25 Jun 2004, Keir Fraser wrote: > > > If Xen interrupted a ring-1 activation then the hypervisor_callback > > stack frame will be pushed onto the stack that was interrupted.OK, I''ve confirmed that I have the following situation: - Plan 9 in ring 1 in kernel mode (i.e. I really mean ring 1) - running while(1); at end of main() with mask set to 0 - Xen deschedules Plan 9 - Xen decides to execute a callback to my Ring 1 Plan 9 - Xen is picking up a junk SS/SP pair from the stack Reason is that there is not, on the Plan 9 Ring 1 stack, an SS/SP pair! There is only the CS/IP as far as I can see - Xen calls my Plan 9 callback in Ring 1, with the SS/SP wrong - Plan 9 hypervisor_callback in Ring 1 does a PUSHAL and takes a page fault - Plan 9 page fault handler dumps the stack frame , and I see this: o trap frame from Xen with good CS/IP, bogus SS/SP, good DS/ES/etc. o hypervisor callback page fault frame good CS/IP, bogus SS/IP o frame from my while(1) with correct CS/IP but (important) no valid SS/IP on the stack So, it seems Xen has descheduled my Plan 9 guest but only the CS/IP is on the stack. Is there any way at all this could happen? it''s very puzzling. When Xen deschedules a domain does it force an interrupt or ... Note: I am handling page faults in both kernel and user mode (Ring 1 and 3) just fine. I can do console I/O. I''m just totally hung up on this callback mess. Also, I should mention: I have not done an LIDT or LTR because I was hoping to just use the Xen default one for the domain (as I do for the GDT). How much trouble could this cause? It seems to have been working fine for a few weeks, so I assumed it was no harm done. thanks ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> So, it seems Xen has descheduled my Plan 9 guest but only the CS/IP is on > the stack. Is there any way at all this could happen? it''s very puzzling. > When Xen deschedules a domain does it force an interrupt or ...Which stack are you talking about here? When Xen first deschedules your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen''s ring-0 stack. When you get a callback, Xen should see that it is ''interrupting'' an existing ring-1 activation, and read the appropriate SS,ESP from its own (ring-0) stack. When it writes the activation frame for teh callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written to your ring-1 stack because the IRET at the end of your callback handler will not be changing privilege levels. The same goes for your page fault: Xen will use the SS,ESP saved on it own stack, and will not write a SS,ESP pair onto your stack.> Also, I should mention: I have not done an LIDT or LTR because I was > hoping to just use the Xen default one for the domain (as I do for the > GDT). How much trouble could this cause? It seems to have been working > fine for a few weeks, so I assumed it was no harm done.Task segments aren''t virtualised, so there is no equivalent of LTR. The quivalent of LIDT is set_trap_table() which you must have called to be taking page faults. -- Keir ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, 26 Jun 2004, Keir Fraser wrote:> Which stack are you talking about here? When Xen first deschedules > your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen''s > ring-0 stack.ok, what interrupt does this?> When you get a callback, Xen should see that it is ''interrupting'' an > existing ring-1 activation, and read the appropriate SS,ESP from its > own (ring-0) stack. When it writes the activation frame for teh > callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written > to your ring-1 stack because the IRET at the end of your callback > handler will not be changing privilege levels.ok, I see your point. I''m really puzzled about this bad ss/sp pair. It makes no sense.> Task segments aren''t virtualised, so there is no equivalent of > LTR. The quivalent of LIDT is set_trap_table() which you must have > called to be taking page faults.good, that''s what I was hoping to hear you say. I''ll keep looking, this is really odd. ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> On Sat, 26 Jun 2004, Keir Fraser wrote: > > > Which stack are you talking about here? When Xen first deschedules > > your while(1), the CPU should write CS,EIP,EFLAGS,SS,ESP onto Xen''s > > ring-0 stack. > > ok, what interrupt does this?Any interrupt. Timer, disc, ... whatever happens to cause Xen to next execute after you disable the mask. Xen always checks the pending and mask flags on return to ring != 0.> > When you get a callback, Xen should see that it is ''interrupting'' an > > existing ring-1 activation, and read the appropriate SS,ESP from its > > own (ring-0) stack. When it writes the activation frame for teh > > callback, it will only write CS,EIP,EFLAGS. SS,ESP will not be written > > to your ring-1 stack because the IRET at the end of your callback > > handler will not be changing privilege levels. > > ok, I see your point. I''m really puzzled about this bad ss/sp pair. It > makes no sense.I''ll take a look at stack traces if you want to post me some suitably annotated ones. -- Keir ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
kmacy@moe make rm -f linux-xen-sparse ln -sf linux-2.4.26-xen-sparse linux-xen-sparse make prefix=/x/eng/raidant/bk/xen-tot/install dist=yes -C xen install make[1]: Entering directory `/x/eng/raidant/bk/xen-tot/xen'' rm -f include/xen/compile.h common/kernel.o rm -f include/asm ln -sf asm-x86 include/asm cd tools/figlet && make && ./figlet Xen 1.3"-devel" 1>>../../include/xen/compile.h && cd ../.. make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' make[2]: `figlet'' is up to date. make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' __ __ _ _____ _ _ \ \/ /___ _ __ / | |___ / __| | _____ _____| | \ // _ \ ''_ \ | | |_ \ __ / _` |/ _ \ \ / / _ \ | / \ __/ | | | | |_ ___) |__| (_| | __/\ V / __/ | /_/\_\___|_| |_| |_(_)____/ \__,_|\___| \_/ \___|_| make -C tools make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools'' make -C figlet make[3]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' make[3]: `figlet'' is up to date. make[3]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools'' make -C common make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/common'' gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3 -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000 -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686 -DNDEBUG -c kernel.c -o kernel.o gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3 -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000 -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686 -DNDEBUG -c sched_bvt.c -o sched_bvt.o sched_bvt.c: In function `bvt_alloc_task'': sched_bvt.c:99: warning: use of cast expressions as lvalues is deprecated sched_bvt.c: In function `bvt_init_scheduler'': sched_bvt.c:413: warning: use of cast expressions as lvalues is deprecated make[2]: *** [sched_bvt.o] Error 1 make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'' make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2 make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'' make: *** [all] Error 2 kmacy@moe gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Sat, Jun 26, 2004 at 03:42:28PM -0700, Kip Macy wrote:> sched_bvt.c: In function `bvt_alloc_task'': > sched_bvt.c:99: warning: use of cast expressions as lvalues is > deprecated > sched_bvt.c: In function `bvt_init_scheduler'': > sched_bvt.c:413: warning: use of cast expressions as lvalues is > deprecated > make[2]: *** [sched_bvt.o] Error 1 > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common''......> gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)ah, looks like i never sent a followup in my "problem building xen" thread (10 jun). sched_atropos.c also used to have the problem, was fixed by r1.951. making similar changes in sched_bvt (diff i use included below) should get it building. this only affects more recent versions of gcc, as when i built a copy under deb-stable the other day and forgot to patch first it worked ok. --- /home/knew/1019/xen/common/sched_bvt.c 2004-06-25 15:03:05.000000000 +0200 +++ sched_bvt.c 2004-06-23 00:52:34.000000000 +0200 @@ -96,7 +96,8 @@ */ int bvt_alloc_task(struct domain *p) { - if ( (BVT_INFO(p) = kmem_cache_alloc(dom_info_cache)) == NULL ) + p->sched_priv = kmem_cache_alloc(dom_info_cache,GFP_KERNEL); + if ( p->sched_priv == NULL ) return -1; return 0; @@ -410,7 +411,8 @@ for ( i = 0; i < NR_CPUS; i++ ) { - CPU_INFO(i) = kmalloc(sizeof(struct bvt_cpu_info)); + schedule_data[i].sched_priv = kmalloc(sizeof(struct bvt_cpu_info), GFP_KERNEL); + if ( CPU_INFO(i) == NULL ) { printk("Failed to allocate BVT scheduler per-CPU memory!\n"); -- Jody Belka knew (at) pimb (dot) org ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> On Sat, Jun 26, 2004 at 03:42:28PM -0700, Kip Macy wrote: > > sched_bvt.c: In function `bvt_alloc_task'': > > sched_bvt.c:99: warning: use of cast expressions as lvalues is > > deprecated > > sched_bvt.c: In function `bvt_init_scheduler'': > > sched_bvt.c:413: warning: use of cast expressions as lvalues is > > deprecated > > make[2]: *** [sched_bvt.o] Error 1 > > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'' > ...... > > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > ah, looks like i never sent a followup in my "problem building xen" > thread (10 jun). sched_atropos.c also used to have the problem, > was fixed by r1.951. making similar changes in sched_bvt (diff i use > included below) should get it building. this only affects more recent > versions of gcc, as when i built a copy under deb-stable the other > day and forgot to patch first it worked ok.Thanks for the patch. Gregor is looking at cleaning up some of the scheduler interface so he''ll incorporate this as part of a larger checkin. Thanks, Ian ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Well, boy do I feel dumb and very relieved. It''s not a bad SS/SP stack pair. Still working out what is *is*, but I think I''m close. ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'' ld -r -o arch.o entry.o trampoline.o acpi.o apic.o delay.o domain_page.o extable.o flushtlb.o i387.o i8259.o idle0_task.o io_apic.o irq.o mm.o mpparse.o nmi.o pci-irq.o pci-pc.o pci-x86.o process.o rwlock.o setup.o smpboot.o smp.o time.o traps.o usercopy.o ld -T xen.lds -N boot/boot.o /x/eng/raidant/bk/xen-tot/xen/common/common.o /x/eng/raidant/bk/xen-tot/xen/drivers/char/driver.o /x/eng/raidant/bk/xen-tot/xen/drivers/acpi/driver.o /x/eng/raidant/bk/xen-tot/xen/drivers/pci/driver.o /x/eng/raidant/bk/xen-tot/xen/arch/x86/arch.o -o /x/eng/raidant/bk/xen-tot/xen/xen-syms /x/eng/raidant/bk/xen-tot/xen/common/common.o(.text+0x4d9c): In function `cmain'': : undefined reference to `memguard_init'' make[2]: *** [default] Error 1 make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'' make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2 make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'' make: *** [all] Error 2 On Sat, 26 Jun 2004, Kip Macy wrote:> kmacy@moe make > rm -f linux-xen-sparse > ln -sf linux-2.4.26-xen-sparse linux-xen-sparse > make prefix=/x/eng/raidant/bk/xen-tot/install dist=yes -C xen install > make[1]: Entering directory `/x/eng/raidant/bk/xen-tot/xen'' > rm -f include/xen/compile.h common/kernel.o > rm -f include/asm > ln -sf asm-x86 include/asm > cd tools/figlet && make && ./figlet Xen 1.3"-devel" > 1>>../../include/xen/compile.h && cd ../.. > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > make[2]: `figlet'' is up to date. > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > __ __ _ _____ _ _ > \ \/ /___ _ __ / | |___ / __| | _____ _____| | > \ // _ \ ''_ \ | | |_ \ __ / _` |/ _ \ \ / / _ \ | > / \ __/ | | | | |_ ___) |__| (_| | __/\ V / __/ | > /_/\_\___|_| |_| |_(_)____/ \__,_|\___| \_/ \___|_| > > make -C tools > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools'' > make -C figlet > make[3]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > make[3]: `figlet'' is up to date. > make[3]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools'' > make -C common > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/common'' > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3 > -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000 > -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include > -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686 > -DNDEBUG -c kernel.c -o kernel.o > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3 > -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000 > -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include > -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686 > -DNDEBUG -c sched_bvt.c -o sched_bvt.o > sched_bvt.c: In function `bvt_alloc_task'': > sched_bvt.c:99: warning: use of cast expressions as lvalues is > deprecated > sched_bvt.c: In function `bvt_init_scheduler'': > sched_bvt.c:413: warning: use of cast expressions as lvalues is > deprecated > make[2]: *** [sched_bvt.o] Error 1 > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'' > make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2 > make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'' > make: *** [all] Error 2 > kmacy@moe gcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info --enable-shared --enable-threads=posix > --disable-checking --disable-libunwind-exceptions --with-system-zlib > --enable-__cxa_atexit --host=i386-redhat-linux > Thread model: posix > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Looks like you''ve got an inconsistent build -- common/kernel.c has been built without NDEBUG defined, in contrast to arch/x86/mm.c. If you change compile flags you need to ''make clean'' for sanity. -- Keir> make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'' > ld -r -o arch.o entry.o trampoline.o acpi.o apic.o delay.o domain_page.o > extable.o flushtlb.o i387.o i8259.o idle0_task.o io_apic.o irq.o mm.o > mpparse.o nmi.o pci-irq.o pci-pc.o pci-x86.o process.o rwlock.o > setup.o smpboot.o smp.o time.o traps.o usercopy.o > ld -T xen.lds -N boot/boot.o > /x/eng/raidant/bk/xen-tot/xen/common/common.o > /x/eng/raidant/bk/xen-tot/xen/drivers/char/driver.o > /x/eng/raidant/bk/xen-tot/xen/drivers/acpi/driver.o > /x/eng/raidant/bk/xen-tot/xen/drivers/pci/driver.o > /x/eng/raidant/bk/xen-tot/xen/arch/x86/arch.o -o > /x/eng/raidant/bk/xen-tot/xen/xen-syms > /x/eng/raidant/bk/xen-tot/xen/common/common.o(.text+0x4d9c): In function > `cmain'': > : undefined reference to `memguard_init'' > make[2]: *** [default] Error 1 > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/arch/x86'' > make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2 > make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'' > make: *** [all] Error 2 > > > On Sat, 26 Jun 2004, Kip Macy wrote: > > > kmacy@moe make > > rm -f linux-xen-sparse > > ln -sf linux-2.4.26-xen-sparse linux-xen-sparse > > make prefix=/x/eng/raidant/bk/xen-tot/install dist=yes -C xen install > > make[1]: Entering directory `/x/eng/raidant/bk/xen-tot/xen'' > > rm -f include/xen/compile.h common/kernel.o > > rm -f include/asm > > ln -sf asm-x86 include/asm > > cd tools/figlet && make && ./figlet Xen 1.3"-devel" > > 1>>../../include/xen/compile.h && cd ../.. > > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > > make[2]: `figlet'' is up to date. > > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > > __ __ _ _____ _ _ > > \ \/ /___ _ __ / | |___ / __| | _____ _____| | > > \ // _ \ ''_ \ | | |_ \ __ / _` |/ _ \ \ / / _ \ | > > / \ __/ | | | | |_ ___) |__| (_| | __/\ V / __/ | > > /_/\_\___|_| |_| |_(_)____/ \__,_|\___| \_/ \___|_| > > > > make -C tools > > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools'' > > make -C figlet > > make[3]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > > make[3]: `figlet'' is up to date. > > make[3]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools/figlet'' > > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/tools'' > > make -C common > > make[2]: Entering directory `/x/eng/raidant/bk/xen-tot/xen/common'' > > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3 > > -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000 > > -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include > > -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686 > > -DNDEBUG -c kernel.c -o kernel.o > > gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -O3 > > -iwithprefix include -Wall -Werror -DMONITOR_BASE=0xFC500000 > > -fomit-frame-pointer -I/x/eng/raidant/bk/xen-tot/xen/include > > -D__KERNEL__ -Wno-pointer-arith -Wredundant-decls -m32 -march=i686 > > -DNDEBUG -c sched_bvt.c -o sched_bvt.o > > sched_bvt.c: In function `bvt_alloc_task'': > > sched_bvt.c:99: warning: use of cast expressions as lvalues is > > deprecated > > sched_bvt.c: In function `bvt_init_scheduler'': > > sched_bvt.c:413: warning: use of cast expressions as lvalues is > > deprecated > > make[2]: *** [sched_bvt.o] Error 1 > > make[2]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen/common'' > > make[1]: *** [/x/eng/raidant/bk/xen-tot/xen/xen] Error 2 > > make[1]: Leaving directory `/x/eng/raidant/bk/xen-tot/xen'' > > make: *** [all] Error 2 > > kmacy@moe gcc -v > > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs > > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > > --infodir=/usr/share/info --enable-shared --enable-threads=posix > > --disable-checking --disable-libunwind-exceptions --with-system-zlib > > --enable-__cxa_atexit --host=i386-redhat-linux > > Thread model: posix > > gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/xen-devel > > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel