[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070622214539.GA8795@rhun.ibm.com>
Date: Fri, 22 Jun 2007 14:45:39 -0700
From: Muli Ben-Yehuda <muli@...ibm.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Yinghai Lu <Yinghai.Lu@....COM>, Andi Kleen <ak@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Vivek Goyal <vgoyal@...ibm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86-64: disable the GART before allocate aperture
On Fri, Jun 22, 2007 at 03:32:53PM -0600, Eric W. Biederman wrote:
> Alan Cox <alan@...rguk.ukuu.org.uk> writes:
>
> > You've got mapped live gart pages from the previous kernel. Even
> > if you disable the gart before a memset you may well have the
> > video card using gart translations and possibly live IOMMU
> > mappings for devices using it via bus mastering - and those will
> > cause you MCE exceptions with a corrupt cpu context flag (ie not
> > nicely recoverable).
>
> The original plan (which we have not followed up on). Was to
> reserve a chunk of any iommu for the kexec on panic kernel. Then to
> just have the second kernel use that unused chunk. This is how we
> treat the normal memory space and it seems a nice and simple
> approach to this kind of problem.
>
> For a normal kexec we should shut everything down before the kernel
> transition so it should not be an issue.
>
> YH do you think you can look at simply reserving a portion of the
> iommu? And having the kexec on panic kernel use the reserved
> portion?
How would this work with an isolation capable IOMMU which has
different address spaces for different devices? (e.g., Calgary which
is in mainline, Intel's VT-d which is coming soon, etc).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists