> I need help understanding how the direct system calls work on the x86_32
> architecture.
>
> What I understand is that when a guest is initialized, it uses the
> hypercall do_set_trap_table to initialize the trap table which calls
> init_int80_direct_trap for system call interrupts.
Correct.
> The later updates the
> int80_desc structure in the VCPU of the guest so that the new address gets
> the callback directly.
Yes, on 32 bit arch (arch/x86/x86_32/traps.c). The definition is
different on 64 bit arch (arch/x86/x86_64/traps.c), int80_desc is not
used.
> What I do not understand is where does the call back occur. Int80 is not
> handles in the x86_32''s entry.S?!!!! So, where is the code that
issues the
> callback?
Here is an explanation how things work on 32 bit arch:
During boot Interrupt Descriptor Table (IDT) is constructed and loaded
onto the CPU(s) (construct_percpu_idt() in arch/x86/smpboot.c). This
table contains description of various interrupt vectors.
When do_set_trap_table() hypercall is issued, vector 0x80 is reset to
point to the guest provided interrupt handler (by
init_int80_direct_trap() in include/asm-x86/processor.h).
Thanks to that, whenever INT 0x80 instruction is executed, the guest
provided handler will be invoked directly, without involving Xen.
That''s how the callback happens: CPU encounters INT 0x80 intruction,
looks up the relevant, guest provided, interrupt handler in the IDT
and invokes it.
>
> Why is architecture is different on x86_64. The entry.S contains an entry
> for int80. Does this affect the performance of the guests?
64 bit architecture is more complicated, because Xen will intercept
interrupt 0x80 (it therefore loads it''s own interrupt handler into
IDT, specifically int80_direct_trap defined in
arch/x86/x86_64/entry.S). The reason why Xen wants to intercept the
interrupts is that we could be executing 32bit guest, or an HVM guest
etc (look through the definition of int80_direct_trap for details).
Hope this helps
Gr(z)egor(z)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel