public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <cminyard@mvista.com>
To: suparna@in.ibm.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Kenneth Sumrall <ken@mvista.com>,
	linux-kernel@vger.kernel.org, lkcd-devel@lists.sourceforge.net
Subject: Re: Kexec, DMA, and SMP
Date: Tue, 11 Feb 2003 08:06:44 -0600	[thread overview]
Message-ID: <3E490374.1060608@mvista.com> (raw)
In-Reply-To: <20030211191027.A2999@in.ibm.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suparna Bhattacharya wrote:

|
|For the sort of problems which Ken is seeing, maybe we can,
|for a start, do without all the modifications to make the
|new kernel run at a different address, if we can assume
|that most i/o is likely is happen on dynamically allocated
|buffers.
|
|We could just reserve a memory area of reasonable size (how
|much ?) which would be used by the new kernel for all its
|allocations. We already have the infrastructure to tell the
|new kernel which memory areas not to use, so its simple
|enough to ask it exclude all but the reserved area.
|By issuing the i/o as early as possible during bootup
|(for lkcd all we need is the block device to be setup for
|i/o requests), we can minimize the amount of memory to
|reserve in this manner.

DMA can occur almost anywhere.  If you restrict the area of DMA, that
means you have to copy the contents to the final destination.  I don't think
we want to do that in many cases.

|
|That might address a large percentage of the regular cases,
|i.e. except where statically allocated buffers could be
|targets for DMA. If we are using in-use (user) pages
|for saving the dump, then there is a possibility of a dump
|getting corrupted by a DMA, but there may be a way to
|minimize that when we chose destination pages to use.

Unless you have some way to mark pages as current DMA targets, you,
you won't be able to do this.  And the problem Ken and I are seeing is
happening after the new kernel has booted. An old DMA operation is
occuring after the new kernel has booted.  That means two kernels would
have to choose the same DMA target areas, and that's fairly unreasonable
to ask, IMHO.

The only reasonable way I can think of to do this is to quiesce the devices
before dumping memory or doing a kexec.  It's not that hard to do, it's just
that a lot of DMA capable device drivers exist that don't do this.

- -Corey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+SQNzmUvlb4BhfF4RAnboAJ4rOL+Amh8F1EvahT9Uko/Y6tPXRwCfV2su
0g582Xllh4TGZ7wQ2YJSsDg=
=FaLb
-----END PGP SIGNATURE-----



  reply	other threads:[~2003-02-11 13:57 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E448745.9040707@mvista.com>
     [not found] ` <m1isvuzjj2.fsf@frodo.biederman.org>
2003-02-08 20:18   ` Kexec, DMA, and SMP Corey Minyard
2003-02-09 18:39     ` Eric W. Biederman
2003-02-10 11:14       ` Kexec on 2.5.59 problems ? Suparna Bhattacharya
2003-02-10 17:09         ` [Fastboot] " Andy Pfiffer
2003-02-10 18:07           ` Eric W. Biederman
2003-02-11  7:21             ` Suparna Bhattacharya
2003-02-11 17:04               ` Andy Pfiffer
2003-02-11 23:46                 ` Andy Pfiffer
2003-02-12  4:29                   ` Eric W. Biederman
2003-02-12 22:31                     ` Andy Pfiffer
2003-02-13  9:50                       ` Suparna Bhattacharya
2003-02-13 15:10                         ` Eric W. Biederman
2003-02-18 10:59                           ` Suparna Bhattacharya
2003-02-18 15:06                             ` Eric W. Biederman
2003-02-10 12:12       ` Kexec, DMA, and SMP Suparna Bhattacharya
2003-02-10 13:56         ` Corey Minyard
2003-02-10 15:07           ` Suparna Bhattacharya
2003-02-10 15:22             ` Corey Minyard
2003-02-10 17:56         ` Eric W. Biederman
2003-02-11  1:35           ` Kenneth Sumrall
2003-02-11  5:08             ` Eric W. Biederman
2003-02-11 17:09               ` Stephen Hemminger
2003-02-11 12:55           ` Suparna Bhattacharya
2003-02-11 13:40             ` Suparna Bhattacharya
2003-02-11 14:06               ` Corey Minyard [this message]
2003-02-11 14:40                 ` Suparna Bhattacharya
2003-02-11 15:20                   ` Corey Minyard
2003-02-12  4:28                     ` Eric W. Biederman
2003-02-12 14:17                       ` Corey Minyard
2003-02-12 14:51                         ` Eric W. Biederman
2003-02-12 16:06                           ` Corey Minyard
2003-02-13 11:13                             ` Suparna Bhattacharya
2003-02-14  3:13                             ` Werner Almesberger
2003-02-14 14:20                               ` Corey Minyard
2003-02-14 18:10                                 ` Werner Almesberger
2003-02-14 18:23                                   ` Corey Minyard
2003-02-14 19:26                                     ` Zwane Mwaikambo
2003-02-14 19:44                                       ` Werner Almesberger
2003-02-14 20:00                                         ` Corey Minyard
2003-02-15  6:03                                           ` Eric W. Biederman
2003-02-16 16:22                                             ` Corey Minyard
2003-02-16 21:48                                               ` Eric W. Biederman
2003-02-17  4:26                                                 ` Corey Minyard
2003-02-17  7:18                                                   ` Eric W. Biederman
2003-02-17 17:32                                                     ` Corey Minyard
2003-02-12  4:47                     ` Suparna Bhattacharya

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=3E490374.1060608@mvista.com \
    --to=cminyard@mvista.com \
    --cc=ebiederm@xmission.com \
    --cc=ken@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkcd-devel@lists.sourceforge.net \
    --cc=suparna@in.ibm.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