From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Thu, 01 Jul 2010 10:00:37 +0000 Subject: Re: [PATCH 0/2] Faster MMU lookups for Book3s v3 Message-Id: <4C2C6745.8040001@suse.de> List-Id: References: <1277903926-12786-1-git-send-email-agraf@suse.de> <4C2C43C0.4000400@redhat.com> <7F9C2F52-3E95-4A22-B973-DACEBC95E5F4@suse.de> <4C2C547E.7010404@redhat.com> In-Reply-To: <4C2C547E.7010404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Avi Kivity Cc: kvm-ppc@vger.kernel.org, KVM list , linuxppc-dev Avi Kivity wrote: > On 07/01/2010 11:18 AM, Alexander Graf wrote: >> >> How does dirty bitmap flushing work on x86 atm? I loop through all >> mapped pages and flush the ones that match the range of the region I >> need to flush. But wouldn't it be a lot more efficient to have an >> hlist in the memslot and loop through that when I need to flush that >> memslot? >> > > x86 loops through the reverse-map link list rooted at the memory > slot. The linked list links all sptes for a single hva. > > So, it's like you describe, except it's an array of lists instead of a > single list. We need per-page rmap lists to be able to remove a > page's sptes in response to an mmu notifier callback, and to be able > to write protect a guest page if it's used as a page table. > But doesn't that mean that you still need to loop through all the hvas that you want to invalidate? Wouldn't it speed up dirty bitmap flushing a lot if we'd just have a simple linked list of all sPTEs belonging to that memslot? Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.suse.de", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 55909B6F06 for ; Thu, 1 Jul 2010 20:00:48 +1000 (EST) Message-ID: <4C2C6745.8040001@suse.de> Date: Thu, 01 Jul 2010 12:00:37 +0200 From: Alexander Graf MIME-Version: 1.0 To: Avi Kivity Subject: Re: [PATCH 0/2] Faster MMU lookups for Book3s v3 References: <1277903926-12786-1-git-send-email-agraf@suse.de> <4C2C43C0.4000400@redhat.com> <7F9C2F52-3E95-4A22-B973-DACEBC95E5F4@suse.de> <4C2C547E.7010404@redhat.com> In-Reply-To: <4C2C547E.7010404@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Cc: linuxppc-dev , KVM list , kvm-ppc@vger.kernel.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Avi Kivity wrote: > On 07/01/2010 11:18 AM, Alexander Graf wrote: >> >> How does dirty bitmap flushing work on x86 atm? I loop through all >> mapped pages and flush the ones that match the range of the region I >> need to flush. But wouldn't it be a lot more efficient to have an >> hlist in the memslot and loop through that when I need to flush that >> memslot? >> > > x86 loops through the reverse-map link list rooted at the memory > slot. The linked list links all sptes for a single hva. > > So, it's like you describe, except it's an array of lists instead of a > single list. We need per-page rmap lists to be able to remove a > page's sptes in response to an mmu notifier callback, and to be able > to write protect a guest page if it's used as a page table. > But doesn't that mean that you still need to loop through all the hvas that you want to invalidate? Wouldn't it speed up dirty bitmap flushing a lot if we'd just have a simple linked list of all sPTEs belonging to that memslot? Alex From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Subject: Re: [PATCH 0/2] Faster MMU lookups for Book3s v3 Date: Thu, 01 Jul 2010 12:00:37 +0200 Message-ID: <4C2C6745.8040001@suse.de> References: <1277903926-12786-1-git-send-email-agraf@suse.de> <4C2C43C0.4000400@redhat.com> <7F9C2F52-3E95-4A22-B973-DACEBC95E5F4@suse.de> <4C2C547E.7010404@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, KVM list , linuxppc-dev To: Avi Kivity Return-path: Received: from cantor.suse.de ([195.135.220.2]:39812 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751174Ab0GAKAn (ORCPT ); Thu, 1 Jul 2010 06:00:43 -0400 In-Reply-To: <4C2C547E.7010404@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 07/01/2010 11:18 AM, Alexander Graf wrote: >> >> How does dirty bitmap flushing work on x86 atm? I loop through all >> mapped pages and flush the ones that match the range of the region I >> need to flush. But wouldn't it be a lot more efficient to have an >> hlist in the memslot and loop through that when I need to flush that >> memslot? >> > > x86 loops through the reverse-map link list rooted at the memory > slot. The linked list links all sptes for a single hva. > > So, it's like you describe, except it's an array of lists instead of a > single list. We need per-page rmap lists to be able to remove a > page's sptes in response to an mmu notifier callback, and to be able > to write protect a guest page if it's used as a page table. > But doesn't that mean that you still need to loop through all the hvas that you want to invalidate? Wouldn't it speed up dirty bitmap flushing a lot if we'd just have a simple linked list of all sPTEs belonging to that memslot? Alex