On 30/03/12 16:40, Alexander Golec wrote: > Does virtio-mmio use irq to communicate with the kernel, or does the kernel wait for it to touch a particular page? Because in qemu virtio-mmio seems to be raising an IRQ, but in the trace I'm observing, the kernel is waiting on a page, so I'm a little confused about the communication. I know very little about virtio-mmio, but the kernel waiting on a page is quite normal (it probably waits for a read request to be satisfied as part of a page fault). Looking at the virtio-mmio DT binding, there is definitely an interrupt used to signal the completion of the request. You may want to look at your platform data to see which interrupt is expected, and compare this with the corresponding QEMU code to make sure the value do match. M. > Alex > > > On Mar 29, 2012, at 11:33 AM, Marc Zyngier wrote: > >> On 29/03/12 16:14, Alexander Golec wrote: >>> In that case, is this warning I'm seeing in both the host and guest relevant? >> >> This has nothing to do with your problem. This warning is there because >> VE doesn't use SPARSE_IRQ yet (among other things). >> >> You can safely ignore it. >> >> M. >>> >>> ------------[ 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<mailto: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 >>> >>> >> >> >> -- >> Jazz is not dead. It just smells funny... >> > > -- Jazz is not dead. It just smells funny...
