From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts Date: Tue, 25 Jan 2011 16:55:29 +0200 Message-ID: <20110125145529.GC15666@redhat.com> References: <20110121233040.22262.68117.stgit@s20.home> <20110124093241.GA28654@amt.cnet> <4D3EA3D3.2050807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , Alex Williamson , kvm@vger.kernel.org, ddutile@redhat.com, chrisw@redhat.com, jan.kiszka@siemens.com To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34954 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750960Ab1AYOzt (ORCPT ); Tue, 25 Jan 2011 09:55:49 -0500 Content-Disposition: inline In-Reply-To: <4D3EA3D3.2050807@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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