Paul Brook wrote:
> On Monday 24 March 2008, Avi Kivity wrote:
>
>> Paul Brook wrote:
>>
>>> On Sunday 23 March 2008, Dor Laor wrote:
>>>
>>>> --- a/qemu/hw/irq.c
>>>> +++ b/qemu/hw/irq.c
>>>> @@ -30,6 +30,8 @@ struct IRQState {
>>>> int n;
>>>> };
>>>>
>>>> +uint32_t qemu_irq_acked[NR_IRQ_WORDS];
>>>>
>>> This is absolute rubbish. The whole point of the IRQ framework is that it
>>> doesn't assume a single flat IRQ controller.
>>>
>> x86 does have a single irq space (even when using cascaded pics or
>> multiple ioapics), called gsi (for generalized system interrupt, or
>> something). It is possible to enumerate all irqs on all platforms that
>> have a finite number of them.
>>
>
> Sure, it's possible to enumerate all the possible IRQ inputs (it's
> effectively
> the same as enumerating all the IRQ sources). It's not possible to say
> anything particularly useful about that enumeration though.
> It's not uncommon for interrupts to be connected to GPIO pins, be inverted,
> or
> have interrupt routings that change dynamically.
>
>
Right, but...
>> It may be better though to identify an irq by a (controller_id,
>> irq_line) pair instead.
>>
>
> That's what qemu_irq is for. Anything else is IMHO wrong.
>
In the case of a kernel virtualization module (like kqemu of kvm) that
is able to handle interrupt injection, qemu_irq is not sufficient since
it is not visible to the kernel. We need some serialization that can
pass the user/kernel boundary. For x86 gsi is a satisfactory serialization.
Even for a pure qemu solution, qemu_irq is difficult to work with. For
the x86 case, we know which vector was successfully injected, and we
need to work out which qemu_irq caused it. This is not deterministic in
the general case (since several irq lines can cause the same vector to
be injected, and since the irq->vector mapping can change), so any
solution will involve heuristics.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
