It sounds like to start with, you should probably look into xentrace:
* Add a new trace record type to xen/include/public/trace.h
* Create a struct, up to 28 bytes, and fill it with the information
you want; then call trace_var().
* In dom0, call xentrace -e [hex address of record type]
* You can use the xentrace_formats to parse the binary file, or write
your own parser; or, wait until I release my xentrace analysis tool
(should be within a week hopefully)
Once you have the basic stuff going, you can think about writing your
own hypervisor-to-domU data path if you don't want to use xentrace.
Peace,
-George
On Fri, Nov 28, 2008 at 11:34 AM, Frederic Beck <frederic.beck@xxxxxxxx> wrote:
> hello
>
> thanks ! Now i see them. I'll be able to begin working a little bit
> more, and understand how the traps work with some printing :)
>
> I'll look also to find a way to log information into a file in order to
> be able to analyze the output.
>
> I may recontact you in case of trouble (in the worst case will be
> beginning of next year, i may have to stop working on that in order to
> switch a different project that needs work done fast)
>
> Thanks a lot
> Fred
>
> Le Fri, 28 Nov 2008 11:19:43 +0000,
> "George Dunlap" <dunlapg@xxxxxxxxx> a écrit :
>
>> Have you tried "xm dmesg"?
>>
>> -George
>>
>> On Thu, Nov 27, 2008 at 4:19 PM, Frederic Beck
>> <frederic.beck@xxxxxxxx> wrote:
>> > 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
>> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home