On Tue, Jan 31, 2012 at 11:47:32AM +0000, Bhushan Bharat-R65777 wrote:
> Hi All,
>
> In my development I came across the state where I need more than 32 kvmslots
>
> QEMU/kvm-all.c:
>
> <cut>
> struct KVMState
> {
> KVMSlot slots[32];
>
> <cut>
>
>
> Followings are the solution I thought of:
> Solution 1:
> Increase the slot to 64 in both KVM and QEMU. I think this will also require to add a new ioctl call so that qemu can come to know on which KVM it is running (whether it is running on 32 slots KVM or 64 slots KVM).
It already exists, its called KVM_CAP_NR_MEMSLOTS (implemented by x86).
> Other solutions:
> a) Decouple the qemu and kvm data structure. QEMU and KVM use some variable size data structure or lists etc. QEMU can keep on adding as many as it wants without knowing how much slots KVM supports.
> b) There are linear search in the KVM slots array in critical path of code of KVM. Does this make some sense using RB-tree, heapsort, balanced binary tree type of solutions?
See discussion at http://lwn.net/Articles/429308/.
x86 optimizes the case of a miss (GFN not mapped by any memslot)
by caching the result into a specially invalid pagetable entry (so
an invalid fault optimizes away the need to walk all memslots).
It would be good to know how much of a problem an increased memslot
array is for PPC.
>
> Looking forward for suggestions.
>
> Thanks
> -Bharat
>
> --
> 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
--
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
