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@xxxxxxxx> wrote:
> Le Tue, 25 Nov 2008 11:57:20 +0000,
> "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|