public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Corey Minyard <cminyard@mvista.com>
Cc: suparna@in.ibm.com, Kenneth Sumrall <ken@mvista.com>,
	linux-kernel@vger.kernel.org, lkcd-devel@lists.sourceforge.net
Subject: Re: Kexec, DMA, and SMP
Date: 11 Feb 2003 21:28:32 -0700	[thread overview]
Message-ID: <m1of5ixgun.fsf@frodo.biederman.org> (raw)
In-Reply-To: <3E4914CA.6070408@mvista.com>

Corey Minyard <cminyard@mvista.com> writes:

> Suparna Bhattacharya wrote:
> 
> |On Tue, Feb 11, 2003 at 08:06:44AM -0600, Corey Minyard wrote:
> |
> |>|
> |>|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.
> |
> |
> |The scope here was just the case that Eric seemed to be
> |trying to address, the way I understood it, and hence a much
> |simpler subset of the problem at hand, since it is not really
> |tackling the rouge/buggy cases. There is no restriction on
> |where DMA can happen, just a block of memory area set aside
> |for the dormant kernel to use when it is instantiated.
> |So this is an area that the current kernel will not use or
> |touch and not specify as a DMA target during "regular"
> |operation.
> 
> You don't understand.  You don't *want* to set aside a block of memory that's
> reserved for DMA.  You want to be able to DMA directly into any user address.
> Consider demand paging.  The performance would suck if you DMA into some
> fixed region then copied to the user address.  Plus you then have another
> resource you have to manage in the kernel.  And you still have to change all
> the drivers, buffer management, etc. to add a flag that says "I'm going to use
> this for DMA" to allocations.  You might as well add the quiesce function, it's
> probably easier to do.  And it doesn't help if you DMA to static memory
> addresses.
> 
> I, too, would like a simpler solution.  I just don't think this is it.

You have it backwards.  It is not about reserving a block of memory
for DMA.  It is about reserving a block of memory to not do DMA in.
Something like 4MB or so.  

The idea is not to let the original kernel touch the reserved block at all.
We just put the kernel that kexec will start in that block of memory.

Eric

  reply	other threads:[~2003-02-12  4:19 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
2003-02-11 14:40                 ` Suparna Bhattacharya
2003-02-11 15:20                   ` Corey Minyard
2003-02-12  4:28                     ` Eric W. Biederman [this message]
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=m1of5ixgun.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=cminyard@mvista.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