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 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.
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
--
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