From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH 0/2] Expose available KVM free memory slot count to help avoid aborts Date: Tue, 25 Jan 2011 19:34:18 +0200 Message-ID: <4D3F099A.6090805@redhat.com> References: <20110121233040.22262.68117.stgit@s20.home> <20110124093241.GA28654@amt.cnet> <4D3EA3D3.2050807@redhat.com> <20110125145529.GC15666@redhat.com> <4D3EE521.4050200@redhat.com> <20110125152334.GF15666@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Alex Williamson , kvm@vger.kernel.org, ddutile@redhat.com, chrisw@redhat.com, jan.kiszka@siemens.com To: "Michael S. Tsirkin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43408 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751301Ab1AYRe3 (ORCPT ); Tue, 25 Jan 2011 12:34:29 -0500 In-Reply-To: <20110125152334.GF15666@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/25/2011 05:23 PM, Michael S. Tsirkin wrote: > On Tue, Jan 25, 2011 at 04:58:41PM +0200, Avi Kivity wrote: > > On 01/25/2011 04:55 PM, Michael S. Tsirkin wrote: > > >> > > >> 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? > > > > Some of the data is validated by the kernel, so it needs a kernel > > copy. Other fields are completely internal to the kernel. > > > > >> 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. > > > > The algorithm is: > > > > page fault: > > for each slot: > > if addr in slot: > > populate spte > > return > > # no slot matches > > mmio > > > > so we have to try out all slots before we find out none of them are needed. > > I see now. Yes, a flag in spte would help. changes in slots would then > have to update all these flags. That's easy, we drop all sptes. -- error compiling committee.c: too many arguments to function