On Tue, Jan 25, 2011 at 12:20:03PM +0200, Avi Kivity wrote: > On 01/24/2011 11:32 AM, Marcelo Tosatti wrote: > >On Fri, Jan 21, 2011 at 04:48:02PM -0700, Alex Williamson wrote: > >> When doing device assignment, we use cpu_register_physical_memory() to > >> directly map the qemu mmap of the device resource into the address > >> space of the guest. The unadvertised feature of the register physical > >> memory code path on kvm, at least for this type of mapping, is that it > >> needs to allocate an index from a small, fixed array of memory slots. > >> Even better, if it can't get an index, the code aborts deep in the > >> kvm specific bits, preventing the caller from having a chance to > >> recover. > >> > >> It's really easy to hit this by hot adding too many assigned devices > >> to a guest (pretty easy to hit with too many devices at instantiation > >> time too, but the abort is slightly more bearable there). > >> > >> I'm assuming it's pretty difficult to make the memory slot array > >> dynamically sized. If that's not the case, please let me know as > >> that would be a much better solution. > > > >Its not difficult to either increase the maximum number (defined as > >32 now in both qemu and kernel) of static slots, or support dynamic > >increases, if it turns out to be a performance issue. > > > > We can't make it unbounded in the kernel, since a malicious user > could start creating an infinite amount of memory slots, pinning > unbounded kernel memory.
How about keeping the slots in userspace memory, access them with copy from user? > If we make the limit much larger, we should start to think about > efficiency. Every mmio vmexit is currently a linear scan of the > memory slot table, which is efficient at a small number of slots, > but not at a large number. We could conceivably encode the "no > slot" information into a bit in the not-present spte. OK, but the slots that Alex here wants to use are presumably mostly not resulting in a pagefault at all, right? Can we split such guys out so they don't slow mmio lookup? Maybe keep *these* in userspace memory. > -- > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
