From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1Oevsd-0003ci-7P for kexec@lists.infradead.org; Fri, 30 Jul 2010 20:08:32 +0000 Subject: Re: In place kexec References: <4C51C878.2090102@zytor.com> <20100729191654.GB28704@redhat.com> <20100729125535.85dfd7da.randy.dunlap@oracle.com> <4C524934.5070806@zytor.com> <1280508817.28006.0.camel@macbook.infradead.org> <20100730183446.GC3332@redhat.com> <20100730185625.GD3332@redhat.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Fri, 30 Jul 2010 13:08:26 -0700 In-Reply-To: (David Woodhouse's message of "Fri\, 30 Jul 2010 20\:46\:12 +0100 \(BST\)") Message-ID: MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: David Woodhouse Cc: Randy Dunlap , Neil Horman , "kexec@lists.infradead.org" , Simon Horman , Andrew Vasquez , "H. Peter Anvin" , linux-driver@qlogic.com, Vivek Goyal David Woodhouse writes: > On Fri, 30 Jul 2010, Eric W. Biederman wrote: > >> David Woodhouse writes: >>> The DMA gets blocked, and you don't have to worry about whether the device was >>> shut down cleanly or not. The device may be unhappy, but when the new kernel's >>> driver loads and reinitialises it, all should be forgiven. >> >> Assuming IOMMU page faults don't cause pain. I seem to remember that >> also being a nasty issue. > > Only if the driver (or the hardware) is so broken that it can't > reccover. There's very little excuse for a driver to have that problem even at > runtime (and fail to recover from such an error)... for a driver to fail to > initialise the hardware even when that driver is first being loaded is > *entirely* fucked. > > Not that it doesn't happen, of course. But do we care? I lump those broken > drivers is the same class as the ones which only work after a warm start from > Windows or Mac OS. The issue is what happens if you take an IOMMU page fault during between shutdown and restart. I seem to remember an IOMMU page fault triggering a machine check on AMD cpus. So maybe it works but my gut impression is simply leaving the IOMMU in a state that is on but not responding could actually make a reboot or kexec less stable than having on-going DMAs stomping on memory. If you can leave it on, without translations and not trapping to software that is a different story. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec