On 03/21/2010 12:15 PM, Michael S. Tsirkin wrote:
Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
any objections to increasing the limit to say 16? That would give us
5 more devices to the limit of 6 per guest.
Increase it to 200, then.
OK. I think we'll also need a smarter allocator
than bus->dev_count++ than we now have. Right?
No, why?
Eventually we'll want faster scanning than the linear search we employ
now, though.
Is the limit visible to userspace? If not, we need to expose it.
I don't think it's visible: it seems to be used in a single
place in kvm. Let's add an ioctl? Note that qemu doesn't
need it now ...
We usually expose limits via KVM_CHECK_EXTENSION(KVM_CAP_BLAH). We can
expose it via KVM_CAP_IOEVENTFD (and need to reserve iodev entries for
those).
--
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
