Bryan Cantrill wrote:
On Sat, Sep 30, 2006 at 11:09:54PM +0100, Jeremy Harris wrote:
Bryan Cantrill wrote:
We will never be doing this: it violates the safety constraint, in
several dimensions. (One of which you outline below.)
I'm interested - which other dimensions do you have in mind?
What if someone puts bad ECC on the text or data required to execute
the bad ECC handler? How does DTrace know what this text and data are
to prohibit it?
Sorry - I wasn't clear. "Someone" here is Dtrace; I'm suggesting
that Dtrace should both place the bad-ECC and log the placed regions.
More generally, what if someone puts bad ECC on text
or data that needs to be accessed at TL>1? How is this handled?
Yes, that is an issue. Can we constrain it in any way? What memory
is accessed at TL>1, and can we restrict it from this type of
tracing? Are there similar issues on non-SPARC architectures?
And what about memory that DTrace itself uses to (for example) store the
lookup table to know how to correct the bogus bad ECC?
What about it? You're not very clear here; please expand.
It's just memory; given the assumption above
that it is Dtrace placing the bad ECC, it would seem possible to
not permit it as a traceable region.
Most generally,
how can one prevent bad ECC from being placed on any word of memory that
is accessed in a context in which a correctable ECC trap cannot be
handled?
By having Dtrace responsible for placing the bad ECC.
- Jeremy Harris
_______________________________________________
networking-discuss mailing list
[email protected]
