On Fri, 2006-08-11 at 19:03 +0900, Jun Koi wrote:
> Good morning,
>
> I am new to Xen, and trying to understand how Xen works. I have some
> questions about virtualization of interrupts on Xen. Thanks in advance
> for all helps.
>
> 1) From papers about Xen architecture found at Xen homepage, Xen
> seemingly intercepts interrupts of Dom1 (paravirtualization). So
> interrupts occur in Dom1's context are sent to Xen, and Xen handles
> them. Is that correct?
similar to interrupts to a native operating systems, interrupts could
occur in just any context (as long as they're not blocked).
the domU never 'receives' the interrupt in a way that it won't even be
able to install a handler for it. the idt belongs to xen, and xen is
where it is actually handled, interrupting whatever used to be running
when it occurred.
> But then how can Dom1 gets the interrupts? For example if int3 occurs
> inside Dom1, Xen intercepts int3, but then how debugger (like gdb) can
> still work in Dom1? Maybe Xen sends that interrupt back to Dom1 after
> processing it in VMM layer?
hardware interrupts in turn drive 'virtual interrupts', which are in the
paravirtualized case a pure software abstraction. in xen, you'll find a
lot of references to a concept called 'event channels', and that's just
that.
so it's xen making then decision on whether a domain interrupt handler
is called, which one's called, when it's called, and whether anything
called at all. don't worry, in practice, xen is doing the right thing,
but that's the way it needs to work. :).
> 2) I have read
> linux-xen-sparse/arch/i386/kernel/{traps-xen.c,traps.c,vmlinux.lds.S},
> and looks like Dom1 still handles interrupts itself? Why, because I
> suppose that the VMM already intercepts those interrupts?
an guest system, whether it's virtualized or not, is not living in a
vacuum. it needs some kind of signalling from the hardware environment,
whether it's virtual or physical, in order to get notified of events.
that's 'asynchronous input' of some kind, not necessarily purelay
hardware interrupt driven, though.
e.g. it needs a regular timer interrupt as well as as notification of
events regarding virtual device interfaces.
so it still has interrupt handlers.
it is, however, not modifying the real IDT. see e.g. trap_init() in
traps-xen.c and read about HYPERVISOR_set_trap_table in the interface
documentations.
> 3) How is linux-xen-sparse/arch/i386/kernel/traps-xen.c compiled,
> while it is not refereed to in
> linux-xen-sparse/arch/i386/kernel/Makefile? I see traps.c is refereed
> instead of traps-xen.c, but I still saw traps-xen.o there after
> compiling? What traps.c does, and what traps-xen.c does, since both
> are very similar to me.
uhhm. now you got me. i noticed the file names changed at some point, i
didn't bother why yet, or how the makefiles changed. maybe someone from
xensource can tell.
regards,
daneil
--
Daniel Stodden
LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München D-85748 Garching
http://www.lrr.in.tum.de/~stodden mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B
signature.asc
Description: This is a digitally signed message part
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home