Hello
I commented out the lines you told me, compiled the hypervisor, and i'm
booting it with my 2.6.26 kernel. It is working fine, my 2 VMs (one
Linux and one XP) are working fine.
I was trying to check the execution by printing out some debug info. I
wanted first to log the info in a specific file, but i had troubles
when compiling with redefinition troubles. I tried sysloging and got
the same troubles.
I finally decided to use the kernel logging mechanisms. I put several
printk and gdprintk in traps.c:trace_pv_trap and do_guest_trap but they
are never printed out (at least i was greping in /var/log).
thus i tried to put some common/xmalloc.c:xfree and xmalloc. I never
see any message neither.
Am i using bad logging mechanisms or simply looking in the wrong
output ?
Thanks
Fred
Le Wed, 26 Nov 2008 17:30:21 +0100,
Frederic Beck <frederic.beck@xxxxxxxx> a écrit :
> Well, stupid question in then end. the hypervisor is in xen/ ....
>
> I managed to compile a 3.3.0 hypervisor and make my 2.6.26 kernel
> running
>
> fighting now with the tools with compiling errors, but it's
> advancing :)
>
> thanks
> Fred
>
> Le Wed, 26 Nov 2008 11:57:03 +0100,
> Frederic Beck <frederic.beck@xxxxxxxx> a écrit :
>
> > Just another quick question.
> >
> > After modifying traps.c, to recompile the hypervisor, do I need to
> > recompile the whole sources with a make world ? Or is it
> > unnecessary ?
> >
> > At the moment I'm running a Debian unstable with the debian packages
> > distribution of Xen with hypervisor 3.2 and kernel 2.6.26, and the
> > 2.6.18 is not running on my computer.
> >
> > The idea would be to compile only the hypervisor, but id did not
> > found yet in the documentation how to do it. I'll keep on looking,
> > but is you have an idea it would be welcomed :)
> >
> > Thanks
> > Fred
> >
> > Le Wed, 26 Nov 2008 09:50:32 +0100,
> > Frederic Beck <frederic.beck@xxxxxxxx> a écrit :
> >
> > > Hello
> > >
> > > > If you're not averse to modifying the hypervisor, you should be
> > > > able to arrange to get what you want.
> > >
> > > Not at all :) It's what i was planning to do in the first case.
> > >
> > > > For 32-bit guests, we allow the system call to trap directly
> > > > from userspace into the PV kernel. But that's actually an
> > > > optimization; it used to be the case that if you disable that
> > > > direct-trap, then it will trap to Xen, and Xen will forward it
> > > > on to the PV kernel. This will make guest system calls slightly
> > > > more expensive, but it will allow you to add the tracing /
> > > > instrumentation you want.
> > > >
> > > > Yes, it looks like if you comment out the following line in
> > > > xen/arch/x86/traps.c:do_set_trap_table():
> > > > if ( cur.vector == 0x80 )
> > > > init_int80_direct_trap(curr);
> > > >
> > > > Then all guest traps, including system call, will go through
> > > > traps.c:do_guest_trap(), which already traces the trap number.
> > > > If you want more information, you can add more trace info there.
> > >
> > > Thanks a lot for your help, i'll give it a try. I just commented
> > > out that part, i'll recompile the hypervisor and play with it.
> > >
> > > I'll let you know how it works out.
> > >
> > > Thanks
> > > Fred
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home