[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] How Xen handles Dom1 interrupts?
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 Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |