Re: [Qemu-devel] plan for device assignment upstream

[Michael S. Tsirkin]

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
>