In that case, is this warning I'm seeing in both the host and guest relevant? ------------[ cut here ]------------ WARNING: at arch/arm/common/gic.c:720 gic_init_bases+0xd8/0x350() Cannot allocate irq_descs @ IRQ16, assuming pre-allocated [<c00141c0>] (unwind_backtrace+0x0/0xf8) from [<c001e058>] (warn_slowpath_common+0x48/0x60) [<c001e058>] (warn_slowpath_common+0x48/0x60) from [<c001e0cc>] (warn_slowpath_fmt+0x30/0x40) [<c001e0cc>] (warn_slowpath_fmt+0x30/0x40) from [<c0437f90>] (gic_init_bases+0xd8/0x350) [<c0437f90>] (gic_init_bases+0xd8/0x350) from [<c0438818>] (ct_ca9x4_init_irq+0x2c/0x34) [<c0438818>] (ct_ca9x4_init_irq+0x2c/0x34) from [<c043840c>] (v2m_init_irq+0x14/0x1c) [<c043840c>] (v2m_init_irq+0x14/0x1c) from [<c0434414>] (init_IRQ+0x14/0x1c) [<c0434414>] (init_IRQ+0x14/0x1c) from [<c0432664>] (start_kernel+0x184/0x2e8) [<c0432664>] (start_kernel+0x184/0x2e8) from [<60008044>] (0x60008044) ---[ end trace 1b75b31a2719ed1c ]--- Alex On Mar 29, 2012, at 11:02 AM, Peter Maydell wrote: > 2012/3/29 Alexander Golec <thejfasi at gmail.com>: >> My question is: qemu is raising an IRQ with n equal to 42. Does that mean >> that the kernel sees IRQ 42 go up? Because it if does, then that's the wrong >> irq. Or is it the handler method that actually picks which number IRQ will >> go up? > > At the moment (since we haven't implemented in-kernel VGIC support) QEMU > emulates the GIC itself, so the device will raise IRQ 42 (or whatever), > and then the emulated GIC will look at priorities and interrupt masks > and so on and will either (a) do nothing or (b) raise either the IRQ > or FIQ line to a particular CPU. So (when using KVM) the kernel will > only see IRQ/FIQ, not the numbered interrupt into the GIC. > > -- PMM -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/android-virt/attachments/20120329/b73df566/attachment-0001.html
