On Sun, Oct 23, 2011 at 15:45, Jan Kiszka <jan.kis...@web.de> wrote: > On 2011-10-23 14:40, Blue Swirl wrote: >> I'm not sure that a full bus is needed for now, even if it could match >> real HW better, since the memory API already provides the separation >> needed. Perhaps this would be needed later to make IRQs per-CPU also, >> or to put IOAPIC also to the bus? > > The ICC interconnects LAPICs and IOAPICs.
But not between CPU core and its LAPIC? > So it should next take over > the management of the local_apics array from apic.c and the ioapics > array from ioapic.c. It could implement generic message delivery > services. Every bus participant would then have a reception handler that > first checks the type and additional fields of a generic ICC message > and, on match, forwards it to the corresponding device model functions. > That would allow for something nicer than global apic_deliver_irq or > ioapic_eoi_broadcast. > > That's clearly beyond the scope of this series but a good reason to > model the ICC as accurately as qdev allows right from the start. OK then, ICC could be a major cleanup.
