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 kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
