On 2011-01-25 06:37, Alex Williamson wrote: > On Mon, 2011-01-24 at 08:44 -0700, Alex Williamson wrote: >> I'll look at how we might be >> able to allocate slots on demand. Thanks, > > Here's a first cut just to see if this looks agreeable. This allows the > slot array to grow on demand. This works with current userspace, as > well as userspace trivially modified to double KVMState.slots and > hotplugging enough pci-assign devices to exceed the previous limit (w/ & > w/o ept). Hopefully I got the rcu bits correct. Does this look like > the right path? If so, I'll work on removing the fixed limit from > userspace next. Thanks, > > Alex > > > kvm: Allow memory slot array to grow on demand > > Remove fixed KVM_MEMORY_SLOTS limit, allowing the slot array > to grow on demand. Private slots are now allocated at the > front instead of the end. Only x86 seems to use private slots, Hmm, doesn't current user space expect slots 8..11 to be the private ones and wouldn't it cause troubles if slots 0..3 are suddenly reserved? > so this is now zero for all other archs. The memslots pointer > is already updated using rcu, so changing the size off the > array when it's replaces is straight forward. x86 also keeps > a bitmap of slots used by a kvm_mmu_page, which requires a > shadow tlb flush whenever we increase the number of slots. > This forces the pages to be rebuilt with the new bitmap size. Is it possible for user space to increase the slot number to ridiculous amounts (at least as far as kmalloc allows) and then trigger a kernel walk through them in non-preemptible contexts? Just wondering, I haven't checked all contexts of functions like kvm_is_visible_gfn yet. If yes, we should already switch to rbtree or something like that. Otherwise that may wait a bit, but probably not too long. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
