Subject: Re: [RFC PATCH 13/17] x86: allow the irq->vector translation to be determined outside of ioapic

From: Gregory Haskins <[email-masked]>
Date: Tue, 31 Mar 2009 16:02:15 -0400

Alan Cox wrote:
> On Tue, 31 Mar 2009 14:43:55 -0400
> Gregory Haskins <[email-masked]> wrote:
>
>   
>> The ioapic code currently privately manages the mapping between irq
>> and vector.  This results in some layering violations as the support
>> for certain MSI operations need this info.  As a result, the MSI
>> code itself was moved to the ioapic module.  This is not really
>> optimal.
>>     
>
> This appears to have been muddled in with the vnet patches ?
>   
Its needed for the kvm-connector patches later in the series, so it was
included intentionally.

On that topic, I probably should have had a TOC of some kind.  Hmm..let
me hack one together now:

Patch 1: Stand-alone "shared-memory signal" construct, used by various
components in vbus/venet
Patches 2-5: Basic vbus infrastructure
Patches 6-7: IOQ construct, similar to virtio-ring.  Used to overlay
ring-like behavior over the shm interface in vbus
Patches 8-12: virtual-ethernet front and backends
Patch 13: io-apic work to expose the irq-vector in x86, needed for
dynirq support
Patches 14-16: KVM host side support
Patch 17: KVM guest side support

Sorry for the confusion :(

Regards,
-Greg