Resend with correct reply threading.
On Fri Nov 14 at 06:54:15 EST in 2008, Hollis Blanchard wrote:
On Thu, 2008-11-13 at 07:44 +1100, Benjamin Herrenschmidt wrote:
Again, why can't we just stick something in the kernel code that
reserves the last page ? It could be in prom.c or it could be called
by
affected 4xx platforms by the platform code, whatever, but the reserve
map isn't really meant for that and will not be passed over from
kernel
to kernel by kexec.
Reserving a page is overkill; only the last 256 bytes are affected. We
need to intercept at the LMB level, because allocations are already
done
there, so by the time we hit bootmem it's way too late.
I agree with Ben we need to have something in the tree to tell kexec
and or the kernel of this errata, unless we adapt the kernel to not
require the memory node be page size aligned.
I instigated a discussion with Josh and Hollis on irc.
I simply don't see a good place to do this in the kernel. It would have
to be before the first lmb_alloc() call, which for safety would put it
inside early_init_devtree() -- along with the other lmb_reserve()
calls.[1]
[1] This is exactly where flat device tree reservations are done, and
that's why the patch I submitted works.
However, ppc_md.probe() hasn't even been called yet, so there's no way
of knowing if we're on an affected system, unless you want to add a
special of_scan_flat_dt() call here.
I think we decided a property is the right way to go, but am not sure
we decided if it should be a specific property in the /cpus/[EMAIL PROTECTED] nodes
or a general property that describes a base and length ... in which
case it is either a property in /memory (cpus nodes are not part of the
system address space, with an independent size 0 address space). It
was also noted if we go the property route. that kexec tools would need
to know about it since it allocates destination pages based on reading
/memory reg ranges, although it also has a hardcoded 768M limit which
might hide this.
I'm open to suggestions, but I don't see a better way than what I
already sent. I think the important part is to call lmb_add() for all
memory, but lmb_reserve() the last 256 bytes before lmb_alloc()
happens.
It sounds like kexec must have some knowledge of the platform and
device
tree already, so is this really a big deal? At any rate, this
conversation is somewhat academic, since there is no kexec on 44x... so
maybe this can be re-addressed when that becomes a real issue.
As discussed, kexec userspace has some ideas of platforms, but its very
general and should not have lists of which cpus have an errata but
should base all its decisions off the device tree.
Alternatives to adding a property include just trimming the memory node
(and fixing the kernel to handle memory size not being page aligned),
and adding an additional node that says this memory is in use. We
should handle the memory size not some big power of 2 anyways, and if
we just create a new node it should not overlap the memory node
anyways. Although we did note that due to current kexec implementation
we can name a node starting with /rtas and use linux,rtas-base and
rtas-size to reserve any 32 bit chunk of memory even to kexec, although
that is considered beyond acceptable for this errata fix (some else
might want to join me in using that to reserve memory for log buffers
across boot).
It has been described to me that the bug affects any access to the 256
bytes, so it would be accurate to describe the memory as not existing
or as this cpu has an errata tnd the dram is really here. I just say
it needs to be described in the device tree. Trimming the memory node
has the advantage that kexec userspace will not need a patch, adding
the cpu has errata property would only require a patch for platofrms
with <768MB (or manual override of the usable memory size via the
command line).
milton
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
