[Top][All Lists]
[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