lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 23 Jun 2007 16:42:16 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Muli Ben-Yehuda <muli@...ibm.com>,
	Yinghai Lu <Yinghai.Lu@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86-64: disable the GART before allocate aperture

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 of it for the base kernel and using soft
> > iommu for the panic kernel, its hardly high performance criticial at this
> > point.
> 
> 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)
> 

Hi Andi,

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)?

> If it's not then swiotlb will also not work because it won't get 
> any memory <4GB.
> 

Will using IOMMU instead of swiotlb give noticeable perfomance boost.
One of the goals is to automatically save the crash dump as soon as
possible and boot back into production kernel to reduce system down
time and reduce availability.

Right now I am trvelling. After OLS will try to come up with a patch
for reserving a couple of IOMMU entries for kdump purposes. Only issue
is that any boot time reservation requirements make it impossible to
enable a feature at run time without rebooting the system.

Thanks
Vivek
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ