On 2011-09-04 14:17, Avi Kivity wrote: > On 08/31/2011 01:53 PM, Jan Kiszka wrote: >> On 2011-08-31 10:25, Peter Maydell wrote: >> > On 30 August 2011 20:28, Jan Kiszka<jan.kis...@web.de> wrote: >> >> Yes, that's the current state. Once we have bidirectional IRQ >> links in >> >> place (pushing downward, querying upward - required to skip IRQ >> routers >> >> for fast, lockless deliveries), that should change again. >> > >> > Can you elaborate a bit more on this? I don't think anybody has >> > proposed links with their own internal state before in the qdev/qom >> > discussions... >> >> That basic idea is to allow >> >> a) a discovery of the currently active IRQ path from source to sink >> (that would be possible via QOM just using forward links) >> >> b) skip updating the states of IRQ routers in the common case, just >> signaling directly the sink from the source (to allow in-kernel IRQ >> delivery or to skip taking some device locks). Whenever some router >> is queried for its current IRQ line state, it would have to ask the >> preceding IRQ source for its state. So we need a backward link. >> >> We haven't thought about how this could be implemented in details yet >> though. Among other things, it heavily depends on the final QOM design. >> > > Looks like a similar path to the memory API. A declarative description > of the interrupt hierarchy allows routes to be precalculated and flattened. > > (here it's strictly an optimization; with the memory API it's a > requirement since kvm requires a flattened representation, and tcg is > greatly simplified by it).
With current kvm device assignment it's mandatory as it only support kernel/kernel IRQ delivery. Only vfio's eventfds will make it optional (but still highly desirable). Jan
signature.asc
Description: OpenPGP digital signature
