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: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver
Date: Thu, 01 Apr 2010 11:58:29 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3

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.

   $ 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?

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





reply via email to

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