> Yes, kdump kernel is generally <4GB . Won't I require IOMMU while I am
> copying the high memory contents in second kernel (lets say 16 GB of memory
> and destination device is not capable of addressing anything more than 4G
> for DMA operation)?
It cannot happen; you don't support mmap on vmco
On Sat, Jun 23, 2007 at 02:14:01AM +0200, Andi Kleen wrote:
> On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
> > > 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 about simply reserving all
On Fri, Jun 22, 2007 at 05:27:50PM -0700, Yinghai Lu wrote:
> Andi Kleen wrote:
> >On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
> >The kdump kernel should be normally all <4GB anyways. You won't
> >need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore.
> >Just don't do that
> But I doubt this was YH's problem - the panic kernel memory
> is always reserved and there shouldn't be any ongoing DMAs in this
> area anyways. And what happens outside the kdump kernel shouldn't matter.
In the kdump case it looks like there is still DMA going on through the
GART on some system
> current I only test kexec only. So clean shut GART in first kernel will help.
>
> where is hook for shutdown? add one in dma_ops?
The low level code could just register its own shutdown handler.
No need to go through dma_ops I think.
-Andi
-
To unsubscribe from this list: send the line "unsub
Andi Kleen wrote:
On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
The kdump kernel should be normally all <4GB anyways. You won't
need any IOMMU for its IO unless you O_DIRECT/sendfile out of /proc/kcore.
Just don't do that (but I suspect it won't work anyways)
If it's not then swiotlb will al
On Saturday 23 June 2007 00:19:51 Alan Cox wrote:
> > 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 about simply reserving all of it for the base kernel and using soft
> iommu for the panic kernel
Alan Cox <[EMAIL PROTECTED]> writes:
> On Fri, 22 Jun 2007 15:57:08 -0700
> Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
>> Alan Cox wrote:
>>
>> > Don't disable it, just don't touch it or any of its mappings. Leave it
>> > *alone*, and use swiotlb. That'll maximise the ability to recover stuff
>> > f
On Fri, 22 Jun 2007 15:57:08 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
>
> > Don't disable it, just don't touch it or any of its mappings. Leave it
> > *alone*, and use swiotlb. That'll maximise the ability to recover stuff
> > from the kexec kernel (since for one you may want
Alan Cox wrote:
Don't disable it, just don't touch it or any of its mappings. Leave it
*alone*, and use swiotlb. That'll maximise the ability to recover stuff
from the kexec kernel (since for one you may want to dump the gart when a
3d app goes kerblam)
How about LinuxBIOS + Kernel ===> Final
On Fri, 22 Jun 2007 15:43:00 -0700
Yinghai Lu <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman wrote:
> > The original design came from thinking about systems where using the iommu
> > was mandatory. I think we almost always reserve memory below 1G for the
> > kexec
> > on panic kernel so it reall
Eric W. Biederman wrote:
The original design came from thinking about systems where using the iommu
was mandatory. I think we almost always reserve memory below 1G for the kexec
on panic kernel so it really shouldn't be an issue in that case. Except
we need to pass an option to force not using
Alan Cox <[EMAIL PROTECTED]> writes:
>> 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 about simply reserving all of it for the base kernel and using soft
> iommu for the panic kernel, its hardly hi
> 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 about simply reserving all of it for the base kernel and using soft
iommu for the panic kernel, its hardly high performance criticial at this
point.
-
To
On 6/22/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Alan Cox <[EMAIL PROTECTED]> writes:
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 kexe
On Fri, Jun 22, 2007 at 03:32:53PM -0600, Eric W. Biederman wrote:
> Alan Cox <[EMAIL PROTECTED]> 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 liv
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Friday 22 June 2007 22:33, Alan Cox wrote:
>> You've got mapped live gart pages from the previous kernel. Even if you
>> disable the gart before a memset
>
> It's probably too late then. It could also interfere with other operations.
> If anything the G
Andi Kleen wrote:
It's probably too late then. It could also interfere with other operations.
If anything the GART should be disabled during kexec shutdown. Perhaps we just
need a suitable suspend function that does that. Eric, any preferences?
how about kdump? do we have chance to call that
Alan Cox <[EMAIL PROTECTED]> 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 ca
On Friday 22 June 2007 22:33, Alan Cox wrote:
> On Fri, 22 Jun 2007 12:31:24 -0700
>
> Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
> > On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> > > [PATCH] x86-64: disable the GART before allocate aperture
> > >
> > > For K8 system: 4G RAM with me
On Fri, 22 Jun 2007 12:31:24 -0700
Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> > [PATCH] x86-64: disable the GART before allocate aperture
> >
> > For K8 system: 4G RAM with memory hole remapping enabled, or more
> > than 4G RAM insta
Muli Ben-Yehuda wrote:
On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
[PATCH] x86-64: disable the GART before allocate aperture
For K8 system: 4G RAM with memory hole remapping enabled, or more
than 4G RAM installed. when mem is allocated for GART, it will do
the memset for clear.
On 6/22/07, Muli Ben-Yehuda <[EMAIL PROTECTED]> wrote:
On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> [PATCH] x86-64: disable the GART before allocate aperture
>
> For K8 system: 4G RAM with memory hole remapping enabled, or more
> than 4G RAM installed. when mem is allocated for G
On Fri, Jun 22, 2007 at 12:19:15PM -0700, Yinghai Lu wrote:
> [PATCH] x86-64: disable the GART before allocate aperture
>
> For K8 system: 4G RAM with memory hole remapping enabled, or more
> than 4G RAM installed. when mem is allocated for GART, it will do
> the memset for clear. and for kexec c
24 matches
Mail list logo
