Re: plan for device assignment upstream

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

 



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.


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


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux