Re: In kernel PIC support: kernel patch

Avi Kivity
2007-06-22T09:46:04Z

Gregory Haskins wrote:
> On Thu, 2007-06-21 at 19:31 +0300, Avi Kivity wrote:
>
>
>> Wait. Looks like APIs are changing meaning according to some mode.
>> Confusion.
>>
>> How about:
>>
>> KVM_INTERRUPT == inject this vector now
>> KVM_EXTINT == drives the processor's interrupt pin (this is handled by
>> the lapic code). input is a vector and type
>> KVM_ISA_INTERRUPT == drives the irq inputs to the PIC. Input is line number.
>> KVM_IOAPIC_INTERRUPT == drives the irq inputs to the IOAPIC. Input is
>> line number.
>> KVM_APIC_MESSAGE == do something to the apic
>>
>> That way, there is no mode (at least in the code), and the APIs keep
>> their meaning.
>>
>
> I actually kind of like the distinction you are making between the
> INTERRUPT, EXTINT, and ISA/IOAPIC APIs and keeping them consistent
> across modes. As you suggested below, the ISA/IOAPIC API probably
> should really stay as one (I vote for retaining the ISA name) since the
> wiring is an invariant of the platform presented by qemu/bochs.
>
>

Well, kvm shouldn't really know how the qemu hardware is wired up. It
can change; and non-qemu userspaces should always be possible.

When we change an irq line, there are three things that matter:

- which chip the line is connected to (PIC 1, PIC2, IOAPIC)
- which line we're talking about
- what level the line is to have

If we allow lists of such triplets to be sent via a single ioctl, then
we can optimize the case where lines are wired together without teaching
kvm about the board layout.

(the ISA name might annoy our non-x86 friends. I see nothing x86
specific about the interface)

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.