Hello I''m looking to get access to information about the system calls in my VMs. Looking through the documentation, i undestood that it was only giving access to generic data about the VM (CPU and memory usage..). I guess i''ll have to look further in the code, or go through xend ? Can you give me some hints and direction for that ? Thanks Fred _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Do you mean system calls (guest process calls into guest kernels), or hypercalls (guest kernel calls into the hypervisor)? If you mean system calls, Xen is not involved; you need to take that up with your guest OSes. :-) If you mean hypercalls, and you want to know the number and timing of them, you can use xentrace, or possibly xenmon. Not much information is gathered about hypercalls at this point beyond the timing and hypercall number. (I''m sure patches to address this would be considered.) Another avenue to look at is the Xen performance counters. There is a performance counter per hypercall; as I understand it, this would give you total hypercalls over the system, not on a per-VM basis. Hopefully that will give you enough to get started! -George On Mon, Nov 24, 2008 at 4:38 PM, Frederic Beck <frederic.beck@loria.fr> wrote:> Hello > > I''m looking to get access to information about the system calls in my > VMs. Looking through the documentation, i undestood that it was only > giving access to generic data about the VM (CPU and memory usage..). > > I guess i''ll have to look further in the code, or go through xend ? > > Can you give me some hints and direction for that ? > > Thanks > Fred > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Le Tue, 25 Nov 2008 11:57:20 +0000, "George Dunlap" <George.Dunlap@eu.citrix.com> a écrit :> Do you mean system calls (guest process calls into guest kernels), or > hypercalls (guest kernel calls into the hypervisor)? > > If you mean system calls, Xen is not involved; you need to take that > up with your guest OSes. :-)Yep, that''s what i was looking for. I was hoping to be able to get the system calls from the guest OSes in the Dom0, but after a few more digging and your answer, i realized that it was not possible. I''ll have to look for another type of virtualization, something that performs emulation such as Qemu, as the idea is to not modify the guest OS. Thanks for your reply Fred _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
If you''re not averse to modifying the hypervisor, you should be able
to arrange to get what you want.
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.
-George
On Tue, Nov 25, 2008 at 1:46 PM, Frederic Beck <frederic.beck@loria.fr>
wrote:> Le Tue, 25 Nov 2008 11:57:20 +0000,
> "George Dunlap" <George.Dunlap@eu.citrix.com> a écrit :
>
>> Do you mean system calls (guest process calls into guest kernels), or
>> hypercalls (guest kernel calls into the hypervisor)?
>>
>> If you mean system calls, Xen is not involved; you need to take that
>> up with your guest OSes. :-)
>
> Yep, that''s what i was looking for. I was hoping to be able to get
the
> system calls from the guest OSes in the Dom0, but after a few more
> digging and your answer, i realized that it was not possible.
>
> I''ll have to look for another type of virtualization, something
that
> performs emulation such as Qemu, as the idea is to not modify the guest
> OS.
>
> Thanks for your reply
> Fred
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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@loria.fr> 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@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@loria.fr> 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@loria.fr> 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@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@loria.fr> 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@loria.fr> 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@loria.fr> 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@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@loria.fr> 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@umich.edu> a écrit : > >> Have you tried "xm dmesg"? >> >> -George >> >> On Thu, Nov 27, 2008 at 4:19 PM, Frederic Beck >> <frederic.beck@loria.fr> 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@loria.fr> 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@loria.fr> 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@loria.fr> 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@lists.xensource.com >> >> > > http://lists.xensource.com/xen-devel >> >> > >> >> > _______________________________________________ >> >> > Xen-devel mailing list >> >> > Xen-devel@lists.xensource.com >> >> > http://lists.xensource.com/xen-devel >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xensource.com >> >> http://lists.xensource.com/xen-devel >> > >> > _______________________________________________ >> > Xen-devel mailing list >> > Xen-devel@lists.xensource.com >> > http://lists.xensource.com/xen-devel >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello,
I need to disable the fast system call handling in xen.
I commented the two lines in xen/arch/x86/traps.c in do_set_trap_table()
if(cur.vector==0x80)
init_int80_direct_trap(curr);
Is this the only change I have to make to disable fast system calls? Because
my system is working after I commented those two lines, but I am unable to
understand how exactly the system calls work without these two lines. Does
it go through do_general_protection fault ?
Please help.
-Swapna
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 28/12/2008 06:17, "Swapna Shingre" <amuswaps@gmail.com> wrote:> Is this the only change I have to make to disable fast system calls? Because > my system is working after I commented those two lines, but I am unable to > understand how exactly the system calls work without these two lines. Does it > go through do_general_protection fault ?Yes. K. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello I had to stay quiet for a few weeks to work on another project. I have a few days ahead, and I was looking at that again. I found some doc explaining the role of the different registers, and understood how to get the info i wanted in them. However, even if i understood how to get the PID of the process, i do not manage to compile Xen. I''m retrieving the value in the ESP pointer, i do the AND with the mask to get the address of the thread_info structure that represents the process. Then i wanna copy this structure in a variable and extract some more info. But the thread_info structure is only defined in the IA64 aprt of the code, and if i add the definition from the kernel, it give me an error at building, telling me that it is declared into a parameter list, and thus scope limited. Any idea ? Thanks Fred Le Fri, 28 Nov 2008 12:05:21 +0000, "George Dunlap" <George.Dunlap@eu.citrix.com> a écrit :> 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@loria.fr> 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@umich.edu> a écrit : > > > >> Have you tried "xm dmesg"? > >> > >> -George > >> > >> On Thu, Nov 27, 2008 at 4:19 PM, Frederic Beck > >> <frederic.beck@loria.fr> 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@loria.fr> 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@loria.fr> 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@loria.fr> 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@lists.xensource.com > >> >> > > http://lists.xensource.com/xen-devel > >> >> > > >> >> > _______________________________________________ > >> >> > Xen-devel mailing list > >> >> > Xen-devel@lists.xensource.com > >> >> > http://lists.xensource.com/xen-devel > >> >> > >> >> _______________________________________________ > >> >> Xen-devel mailing list > >> >> Xen-devel@lists.xensource.com > >> >> http://lists.xensource.com/xen-devel > >> > > >> > _______________________________________________ > >> > Xen-devel mailing list > >> > Xen-devel@lists.xensource.com > >> > http://lists.xensource.com/xen-devel > >> > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel