The new implementation also uses standard kernel {rb,interval}-tree
and hash table implementation as its basic data structures, so it
automatically benefits from any generic improvements to these.
All for the low price of just 174 net lines of code added.
I think the best thing to do here is to provide a patch series that
splits the individual changes so that they can be reviewed and their
separate merits evaluated.
Another thing that I dislike about KVM_SET_USER_MEMORY_REGION is that
IMO userspace should provide all memslots at once, for an atomic switch
of the whole memory array. (Or at least I would like to see the code;
it might be a bit tricky because you'll need code to compute the
difference between the old and new arrays and invoke
kvm_arch_prepare/commit_memory_region). I'm not sure how that would
interact with the active/inactive pair that you introduce here.
+1
One issue I am aware of is resizing/splitting slots, especially due to
arrays like rmap + dirty bitmaps.
BTW: what are your thoughts regarding converting the rmap array on
x86-64 into some dynamic datastructre (xarray etc)? Has that already
been discussed?
Paolo
--
Thanks,
David / dhildenb
