Re: [Android-virt] [PATCH v5 05/13] ARM: KVM: Inject IRQs and FIQs from userspace

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On 2011-12-11 23:53, Christoffer Dall wrote:
> On Sun, Dec 11, 2011 at 5:35 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 11 December 2011 22:12, Peter Maydell <peter.maydell@linaro.org> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]