Re: [PATCH v3 1/1] Shared memory uio_pci driver

[Avi Kivity <avi@redhat.com>]

On 04/01/2010 01:59 PM, Michael S. Tsirkin wrote:
> On Thu, Apr 01, 2010 at 11:58:29AM +0300, Avi Kivity wrote:
>    
>> On 03/31/2010 12:12 PM, Michael S. Tsirkin wrote:
>>      
>>>
>>>        
>>>>     $ echo 4>   /sys/.../msix/allocate
>>>>     $ # subdirectories 0 1 2 3 magically appear
>>>>     $ # bind fd 13 to msix
>>>>
>>>>          
>>> There's no way to know, when qemu starts, how many vectors will be used
>>> by driver.  So I think we can just go ahead and allocate as many vectors
>>> as supported by device at the moment when the first eventfd is bound.
>>>
>>>        
>> That will cause a huge amount of vectors to be allocated.  It's better
>> to do this dynamically in response to guest programming.
>>      
> guest unmasks vectors one by one.
> Linux does not have an API to allocate vectors one by one now.
>    

Well, maybe it should.  I'm worried that the guest could exhaust host 
irqs if we allocate the maximum amount.

>> What's irqcontrol?
>>      
> uio core accepts 32 bit writes and passes the value written
> as int to an irqcontrol callback in the device.
>    

I see.  In this case I withdraw my earlier objection about using write() 
to control eventfd binding, as it's clearly interrupt related.  I still 
prefer an explicit ioctl though.  I think you suggested to allow 
irqcontrol to support >4 byte writes, that should also work.


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