Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932962AbYFFViW (ORCPT ); Fri, 6 Jun 2008 17:38:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757858AbYFFViM (ORCPT ); Fri, 6 Jun 2008 17:38:12 -0400 Received: from mtagate8.uk.ibm.com ([195.212.29.141]:32452 "EHLO mtagate8.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753421AbYFFViK (ORCPT ); Fri, 6 Jun 2008 17:38:10 -0400 Date: Sat, 7 Jun 2008 00:36:59 +0300 From: Muli Ben-Yehuda To: Grant Grundler Cc: FUJITA Tomonori , linux-kernel@vger.kernel.org, mgross@linux.intel.com, linux-scsi@vger.kernel.org Subject: Re: Intel IOMMU (and IOMMU for Virtualization) performances Message-ID: <20080606213659.GC15085@il.ibm.com> References: <20080604235053K.fujita.tomonori@lab.ntt.co.jp> <20080606202119.GQ15085@il.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1371 Lines: 31 On Fri, Jun 06, 2008 at 02:28:36PM -0700, Grant Grundler wrote: > Historically the IOMMUs needed physically contiguous memory and > resizing essentially meant quiescing all DMA, moving the IO Pdir > data to the new bigger location, allocating a new bitmap and cloning > the state into that as well, and then resuming DMA operations. The > DMA quiesce requirement effectively meant a reboot. My understanding > of Vt-d is the ranges can be added range at a time and thus can be > easily resized. VT-d uses a multi-level page-table, so there would be no problem resizing. > But it will mean more complex logic in the IOMMU bitmap handling for > a domain which owns multiple bitmaps and thus a slightly higher CPU > utilization cost. At least that's my guess. I'm not working on any > IOMMU code lately... The logic seems pretty simple to me, all we need to do is keep track of how many entries are currently allocated in the bitmap vs. the size of the bitmap. Once we get to the half-way point, double the size of the bitmap. Having said that, I'm not sure it's worth it, and have no plans to implement it :-) Cheers, Muli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/