Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

[Eric W. Biederman]

Hirokazu Takahashi <taka@xxxxxxxxxxxxx> writes:

> Hi Eric,
> 
> > > Hi Vivek and Eric,
> > > 
> > > IMHO, why don't we swap not only the contents of the top 640K
> > > but also kernel working memory for kdump kernel?
> > > 
> > > I guess this approach has some good points.
> > > 
> > >  1.Preallocating reserved area is not mandatory at boot time.
> > >    And the reserved area can be distributed in small pieces
> > >    like original kexec does.
> > > 
> > >  2.Special linking is not required for kdump kernel.
> > >    Each kdump kernel can be linked in the same way,
> > >    where the original kernel exists.
> > > 
> > > Am I missing something?
> > 
> > Preallocating the reserved area is largely to keep it from
> > being the target of DMA accesses.  Since we are not able
> > to shutdown any of the drivers in the primary kernel running
> > in a normal swath of memory sounds like a good way to get
> > yourself stomped at the worst possible time.
> 
> So what do you think my another idea?

I have proposed it.  I think ia64 already does that.
It has been pointed that the PowerPC kernel occasionally runs
with the mmu turned off. So it is not a technique the is 100%
portable.
 
> I think we can always make a kdump kernel mapped to the same virtual
> address. So we will be free from caring about the physical address
> where the kdump kernel is loaded.
> 
> I believe the memsection functionality which LHMS project is working
> on would help this.

You don't need anything fancy except to build the page tables
during bootup.  However there are a few potential gotchas
with respect to using large pages, that can give 4MiB or
greater alignment restrictions on the kernel.  Code wise
the gotcha is moving the kernel's .text section into what
is essentially the vmalloc portion of the address space.
For x86_64 the kernels virtual address is already decoupled from the
physical addresses, so it is probably easier.

Most of this just results in easier management between the pieces.
Which is a good thing.  However at the moment I don't think it
simplifies any of the core problems.  I still need to reserve
a large hunk of physical address space early on before any
DMA transactions are setup to hold the new kernel.

So while I am happy to see patches that improve this I don't
actually care right now.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/