[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] plan for device assignment upstream
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] plan for device assignment upstream |
Date: |
Wed, 04 Jul 2012 14:24:45 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
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.
--
error compiling committee.c: too many arguments to function