From: "Christian Schaubschläger" <christian.schaubschlaeger@gmx.at>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Khalid Aziz <khalid.aziz@hp.com>, kexec@lists.infradead.org
Subject: Re: Problem with kexec on i386, linux-3.5
Date: Fri, 17 Aug 2012 08:58:37 +0200 [thread overview]
Message-ID: <502DEB9D.7010308@gmx.at> (raw)
In-Reply-To: <877gsy4p6h.fsf@xmission.com>
>> I bistcted that down to this patch:
>>
>> commit b566a22c23327f18ce941ffad0ca907e50a53d41
>> Author: Khalid Aziz <khalid.aziz@hp.com>
>> Date: Fri Apr 27 13:00:33 2012 -0600
>>
>> PCI: disable Bus Master on PCI device shutdown
>>
>> Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI
>> devices do not continue to DMA data after shutdown. This can cause memory
>> corruption in case of a kexec where the current kernel shuts down and
>> transfers control to a new kernel while a PCI device continues to DMA to
>> memory that does not belong to it any more in the new kernel.
>>
>> I have tested this code on two laptops, two workstations and a 16-socket
>> server. kexec worked correctly on all of them.
>>
>> Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>
>>
>> Without this patch, int13 works fine here! If anyone needs more
>> information, just let me know!
> Which leads to an interesting conundrum.
>
> kexec appears to be more reliable for booting another kernel with this
> patch applied. This patch does kill the entier use case of making BIOS
> calls, and I suspect it also does nasty things to alpha bootloaders.
>
> My gut feel is that the trampoline code should reenable bus mastering
> on the devices that lie behind int13, but I don't know how practical
> that suggestion is in reality.
One could make this patch optional... e.g. let kexec tell the running kernel whether or not to disable bus mastering before booting the new one (something like 'kexec --disable-bus-mastering -l /boot/new_kernel.bin'). Don't know if this would be practicable...
Christian
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-08-17 6:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-24 17:49 Problem with kexec on i386, linux-3.5 Christian Schaubschläger
2012-08-14 3:31 ` Eric W. Biederman
2012-08-16 12:41 ` Christian Schaubschläger
2012-08-16 19:22 ` Eric W. Biederman
2012-08-17 6:58 ` Christian Schaubschläger [this message]
2012-09-07 15:16 ` Khalid Aziz
2012-09-07 20:29 ` Khalid Aziz
2012-09-10 6:00 ` Christian Schaubschläger
2012-09-10 16:29 ` Khalid Aziz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=502DEB9D.7010308@gmx.at \
--to=christian.schaubschlaeger@gmx.at \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=khalid.aziz@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox