On Wed, Jul 04, 2012 at 02:24:45PM +0300, Avi Kivity wrote: > On 07/04/2012 01:42 PM, Michael S. Tsirkin wrote: > > On Mon, Jul 02, 2012 at 12:43:48PM +0300, Avi Kivity wrote: > >> On 07/02/2012 12:30 PM, Jan Kiszka wrote: > >> > On 2012-07-02 11:18, Michael S. Tsirkin wrote: > >> >> I've been thinking hard about Jan's patches for device > >> >> assignment. Basically while I thought it makes sense > >> >> to make all devices: assignment and not - behave the > >> >> same and use same APIs for injecting irqs, Anthony thinks there is huge > >> >> value in making irq propagation hierarchical and device assignment > >> >> should be special cased. > >> > > >> > On the long term, we will need direct injection, ie. caching, to allow > >> > making it lock-less. Stepping through all intermediate layers will cause > >> > troubles, at least performance-wise, when having to take and drop a lock > >> > at each stop. > >> > >> So we precalculate everything beforehand. Instead of each qemu_irq > >> triggering a callback, calculating the next hop and firing the next > >> qemu_irq, configure each qemu_irq array with a function that describes > >> how to take the next hop. Whenever the configuration changes, > >> recalculate all routes. > >> > >> For device assignment or vhost, we can have a qemu_irq_irqfd() which > >> converts a qemu_irq to an eventfd. If the route calculations determine > >> that it can be serviced via a real irqfd, they also configure it as an > >> irqfd. Otherwise qemu configures a poll on this eventfd and calls the > >> callback when needed. > > > > This is more or less what I had in mind and what Anthony objects to. > > Can you post an interface that supports this? Then we can see exactly > what is objectionable.
There wasn't a patch, just discussion. I'll try to sketch an API so people can respond more specifically. > > -- > error compiling committee.c: too many arguments to function >
