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 17:23:34 +0200 Message-ID: <20110125152334.GF15666@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> 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]:64876 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571Ab1AYPX4 (ORCPT ); Tue, 25 Jan 2011 10:23:56 -0500 Content-Disposition: inline In-Reply-To: <4D3EE521.4050200@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > -- > error compiling committee.c: too many arguments to function