|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH v3 1/1] Shared memory uio_pci driver |
Date: | Thu, 01 Apr 2010 14:27:02 +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 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 msixThere'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
[Prev in Thread] | Current Thread | [Next in Thread] |