On Thu, May 23, 2013 at 09:46:07AM +0200, Stefan Hajnoczi wrote: > On Wed, May 22, 2013 at 09:48:21PM +0800, Amos Kong wrote: > > On Wed, May 22, 2013 at 11:32:27AM +0200, Stefan Hajnoczi wrote: > > > On Wed, May 22, 2013 at 12:57:35PM +0800, Amos Kong wrote: > > > > I try to hotplug 28 * 8 multiple-function devices to guest with > > > > old host kernel, ioeventfds in host kernel will be exhausted, then > > > > qemu fails to allocate ioeventfds for blk/nic devices. > > > > > > > > It's better to add detail error here. > > > > > > > > Signed-off-by: Amos Kong <akong@xxxxxxxxxx> > > > > --- > > > > kvm-all.c | 4 ++++ > > > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > > > It would be nice to make kvm bus scalable so that the hardcoded > > > in-kernel I/O device limit can be lifted. > > > > I had increased kernel NR_IOBUS_DEVS to 1000 (a limitation is needed for > > security) in last Mar, and make resizing kvm_io_range array dynamical. > > The maximum should not be hardcoded. File descriptor, maximum memory, > etc are all controlled by rlimits. And since ioeventfds are file > descriptors they are already limited by the maximum number of file > descriptors. For implement the dynamically resize the kvm_io_range array, I re-allocate new array (with new size) and free old array when the array flexes. The array is only resized when add/remove ioeventfds. It will not effect the perf. > Why is there a need to impose a hardcoded limit? I will send a patch to fix it. > Stefan -- Amos. -- 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
