Re: [KVM PATCH v7 2/2] KVM: add iosignalfd support

From: Avi Kivity
Date: Sun Jun 21 2009 - 09:54:54 EST


On 06/18/2009 05:09 PM, Gregory Haskins wrote:
Avi Kivity wrote:
On 06/18/2009 03:09 PM, Gregory Haskins wrote:
+config KVM_MAX_IOSIGNALFD_ITEMS
+ int "Maximum IOSIGNALFD items per address"
+ depends on KVM
+ default "32"
+ ---help---
+ This option influences the maximum number of fd's per PIO/MMIO
+ address that are allowed to register
+


Is there a per-vm limit on iosignalfds? if not, userspace can exhaust
kernel memory in that way.

Yeah, its already naturally limited by the maximum number of MMIO/PIO
devices we can register (today this is 6 per VM). I should have
documented that fact somewhere, tho.

We need to raise this limit drastically and to expose it.

Any suggestions on a target #? 512?

Let's say 20 devices with 16 queues each. That gives 320 fds. So 512 seems like a good choice for now.

But don't make it Kconfigurable, there's no way the user will know what to put there.
No, a u16 will naturally expand to a u64, and the emulator will
generate the correct value.

Right, I understand that part. What I mean specifically is at run-time
when the IO comes in. I was thinking I would need to do a memcmp
against the u64 and the data-register and it was hurting my head trying
to figure out what pointer to pass to memcmp.

<lightbulb turns on>

Duh, I can just load the data-register into a u64 and check equality.
Nevermind, I am a dumbass ;)

I see on your v8 what the load means. It's not so pretty. But we can have generic code do the load and pass a u64 instead of a pointer.

But please, only after this goes in.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/