Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757395AbZJLRgy (ORCPT ); Mon, 12 Oct 2009 13:36:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757329AbZJLRgx (ORCPT ); Mon, 12 Oct 2009 13:36:53 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:35404 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757310AbZJLRgw (ORCPT ); Mon, 12 Oct 2009 13:36:52 -0400 Date: Mon, 12 Oct 2009 10:35:06 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: David Woodhouse cc: "Rafael J. Wysocki" , Greg Kroah-Hartman , Linux Kernel Mailing List , Adrian Bunk , Andrew Morton , Natalie Protasevich Subject: Re: 2.6.32-rc4: Reported regressions from 2.6.31 In-Reply-To: <1255362962.32729.63.camel@macbook.infradead.org> Message-ID: References: <1255342738.24732.265.camel@macbook.infradead.org> <1255362962.32729.63.camel@macbook.infradead.org> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1798 Lines: 43 On Mon, 12 Oct 2009, David Woodhouse wrote: > > > The other solution would be to just _enable_ (and do all the setup) of the > > IOMMU early. And then just leave a legacy mapping for the IOMMU, and then > > _after_all_devices_are_set_up_ can you then remove the legacy mapping. > > That involves allocating a _shitload_ of page tables for a 1:1 mapping > of all of physical memory. I don't think that's true. Nobody cares about "all physical memory". For one thing, we know that anything that we consider to be normal memory (ie it's listed in the e820 tables as RAM) can't be all that interesting, since the BIOS definitely released that to us. That said, as long as the IOMMU is clearly enabled after the quirks have run, for this particular case we don't much care. But I could also imagine something similar happening for some BIOS-enabled ethernet device being set up to listen to packets into some BIOS data areas (left-overs from whatever bootp thing or other), which doesn't have a quirk, and which ends up doing DMA until we actually load the driver. Of course, we'd hope that the DMA just fails and nothing bad really happens (hopefully the driver re-init will clear up any hung device). But I can also imagine the hardware simply being really really unhappy, and not recovering. So in many ways it would be safest to leave memory that we don't know about and we don't own as DMA'able in the IOMMU. And no, I don't think it would be a shitload of pages. Quite the reverse. It's probably not very many at all. Linus -- 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/