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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
