On Mon, Mar 29, 2010 at 11:59:24PM +0300, Avi Kivity wrote: > On 03/28/2010 10:48 PM, Cam Macdonell wrote: >> On Sat, Mar 27, 2010 at 11:48 AM, Avi Kivity<avi@xxxxxxxxxx> wrote: >> >>> On 03/26/2010 07:14 PM, Cam Macdonell wrote: >>> >>>> >>>>> I'm not familiar with the uio internals, but for the interface, an >>>>> ioctl() >>>>> on the fd to assign an eventfd to an MSI vector. Similar to ioeventfd, >>>>> but >>>>> instead of mapping a doorbell to an eventfd, it maps a real MSI to an >>>>> eventfd. >>>>> >>>>> >>>> uio will never support ioctls. >>>> >>> Why not? >>> >> Perhaps I spoke too strongly, but it was rejected before >> >> http://thread.gmane.org/gmane.linux.kernel/756481 >> >> With a compelling case perhaps it could be added. >> > > Ah, the usual "ioctls are ugly, go away". > > It could be done via sysfs: > > $ cat /sys/.../msix/max-interrupts > 256 This one can be discovered with existing sysfs. > $ 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. > $ 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. > $ # 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. > -- > Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
