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 20:00:15 +0200 Message-ID: <20110125180015.GD17734@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> <4D3F099A.6090805@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]:56122 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753654Ab1AYSAh (ORCPT ); Tue, 25 Jan 2011 13:00:37 -0500 Content-Disposition: inline In-Reply-To: <4D3F099A.6090805@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jan 25, 2011 at 07:34:18PM +0200, Avi Kivity wrote: > 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. Ah, right. Hmm cpu has no flag to distinguish mmio sptes somehow already? > -- > error compiling committee.c: too many arguments to function