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.

Reply via email to