On 2011-12-11 23:53, Christoffer Dall wrote: > On Sun, Dec 11, 2011 at 5:35 PM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >> On 11 December 2011 22:12, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >>> (Actually what would be clearest would be if the ioctl took the >>> (interrupt-target, interrupt-line-for-that-target, value-of-line) >>> tuple as three separate values rather than encoding two of them into >>> a single integer, but I assume there's a reason we can't have that.) >> >> Have you thought about how this encoding scheme would be extended >> when we move to using the VGIC and an in-kernel interrupt controller >> implementation, incidentally? I haven't really looked into that at >> all, but I assume that then QEMU is going to start having to tell >> the kernel it wants to deliver interrupt 35 to the GIC, and so on... >> >> > no, I haven't looked into that at all. My plan was to decipher the > common irq, ioapic stuff for x86 and see how much we can re-use and if > there will be some nice way to either use what's there or change some > bits to accomodate both existing archs and ARM. But the short answer > is, no not really, I was focusing so far on getting a stable > implementation upstream. > > yes, we are going to have to have some interface with QEMU for this > and if we need new features from what's already there that should > probably be discussed in the same round as the mechanism for handing > of CP15 stuff to QEMU that we touched upon earlier. Enabling in-kernel irqchips usually means "switching worlds". So the semantics of these particular IRQ inject interface details may change without breaking anything. However, things might look different if there will be a need to inject also the CPU IRQs directly, not only the irqchip inputs. In that case, it may make some sense to reserve more space for interrupt types than just one bit and use a common encoding scheme. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
