RE: [RFC] Better MCA recovery on IPF

["Alberto Munoz" <amunoz@vmware.com>]

Hi Tony,

Thank you for the clarification.

> > I still believe that a failed speculative read (for example 
> > of poisoned data) will generate an MCA. Perhaps someone from
> > Intel can confirm or deny?
> 
> It depends on exactly what you mean by "speculative read", and
> even there it is not architecturally defined, so different
> implementations may behave differently ("Ask not the elves for
> advice for they will say both yes and no" - Tolkien).
> 
> "Speculative" reads from memory as a result of lfetch, or a code
> fetch for a mispredicted branch that reference poisoned data may
> not generate an MCA (since the processor can know that the poisoned
> data will not be consumed.  Speculative reads from "ld.s" have
> less scope to avoid the MCA

I actually meant a read generated as a result of a ld.s. 

By the way, what do you mean by "less scope to avoid the MCA"? this statement
seems to imply that some existing implementations do it (avoid generating and
MCA when a ld.s accesses poisoned data) under some circumstances. Can you
elaborate?

What implementation of the Itanium processor supports avoiding MCAs from
lfetch or code fetch operations? I don't think Itanium 1 or 2 do this. How
about Madison?

> There's a new bit coming for PAL_PROC_{GET,SET}_FEATURES which
> will at least tell you (and may allow you to request, if the
> implementation supports it) whether the processor will respond
> to poison with CMCI, or upgrade to MCA ... watch the web for a
> spec update to the SDV

I assume this is only for the write path (not the read). As a CMCI on the
read path cannot possibly guarantee containment (prevent unmarked corrupt
data from making it to a register and eventually to memory, disk or the
network). Unless the (architectural) position is that an OS sets this bit at
its own risk...

Thanks again,

Bert Munoz
 
> -Tony
> 
>