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

[Avi Kivity]

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