Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

[Avi Kivity <avi@redhat.com>]

On 09/04/2011 05:43 PM, Anthony Liguori wrote:
>> Pet peeve - saying something is "by definition" a hack is just rhetoric
>> unless the definition of device state is "something that cannot be
>> extracted and externalized". Let's avoid this.
>
>
> Likewise, I would prefer to avoid stating that something is a hard 
> requirement in the absence of concrete use-cases.

Agree.  But let's not fight rhetoric with rhetoric.

I also agree that if it were just the 440fx, then we could have a 
private channel between device assignment and the ioapic.  But if there 
are more use cases, it calls for a generic solution.

> I do think the definition of device state is more or less something 
> that is opaque and owned by the device.  The more we externalize the 
> device state, the more we have to deal with compatibility (even if 
> it's just internal compatibility).  This makes modularity hard because 
> there's too many things with complex dependencies.

That depends on the number of special cases we'll see.  I really have no 
insight here.

>
>> In fact it's exactly what we do with the memory API. Memory routing is
>> part of device state, yet we expose it to the memory API and let it do
>> its thing instead of going through the hierarchy on every single memory
>> access.
>
> Yes, and the memory API is complicated and invasive :-)  But it's 
> worth it at the end of the day (although I think it could be 
> simplified at the expensive of not allowing as much flattening).

(we should have spent a few hours at kf2011 to convince you that this is 
impossible)

>
> What I'm concerned about is an attempt to globally track IRQ routing.  
> I can imagine constructing a board where you have two simple devices 
> that have level triggered interrupts and wanting to tie them to a 
> single input pin.  A simple OR gate would be sufficient to do this.  
> Having to make an OR gate an IRQ router seems like far too much 
> complexity to me.

Depends on the API.  If Pin has a method pin_add_tristate_input(), then 
it becomes trivial.

> I think we need to strive to keep simple things simple.

Too late.

-- 
error compiling committee.c: too many arguments to function