qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
Date: Thu, 1 Apr 2010 13:59:29 +0300
User-agent: Mutt/1.5.19 (2009-01-05)

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.

>>>    $ echo 13>  /sys/.../msix/2/bind-fd
>>>      
>> I think that this one can't work, both fd 13 and sysfs file will get
>> closed when /bin/echo process exits.
>>    
>
> I meant figuratively.  It's pointless to bind an eventfd from a shell.   
> You'd use fprintf() from qemu to bind the eventfd.
>
>>>    $ # from now on, msix interrupt 2 will call eventfd_signal() on fd 13
>>>
>>> Call me old fashioned, but I prefer ioctls.
>>>      
>> I think we will have to use ioctl or irqcontrol because of lifetime
>> issues outlines above.
>>    
>
> The lifetime issues don't exist if you do all that from qemu.  That's  
> not to say I prefer sysfs to ioctl.
>
> What's irqcontrol?

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]