qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 04 Sep 2011 18:03:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]