MTT table entry with poison data

[leBsky]

when smmtt or iomtt in use, it is possible that MTT table walk gets poisoned data, what exception should be raised in this case?

[ved-rivos]

The hart would raise a hardware-error exception.

The IOMTT is expected to report the attempted poison consumption to the RAS subsystem and abort the DMA transaction. If the aborted transaction is a write then the IO bridge may discard the write; the details of how the write is discarded are implementation defined. If the IO protocol requires a response for write transactions (e.g., AXI) then a response as defined by the IO protocol may be generated by the IO bridge (e.g., SLVERR on BRESP - Write Response channel). For PCIe, for example, write transactions are posted and no response is returned when a write transaction is discarded. If the faulting transaction is a read then the device expects a completion. The IO bridge may provide a completion to the device. The data, if returned, in such completion is implementation defined; usually it is a fixed value such as all 0 or all 1. A status code may be returned to the device in the completion to indicate this condition. For AXI, for example, the completion status is provided by SLVERR on RRESP (Read Data channel). For PCIe, for example, the completion status field may be set to "Unsupported Request" (UR) or "Completer Abort" (CA).

[leBsky]

The hart would raise a hardware-error exception.

The IOMTT is expected to report the attempted poison consumption to the RAS subsystem and abort the DMA transaction. If the aborted transaction is a write then the IO bridge may discard the write; the details of how the write is discarded are implementation defined. If the IO protocol requires a response for write transactions (e.g., AXI) then a response as defined by the IO protocol may be generated by the IO bridge (e.g., SLVERR on BRESP - Write Response channel). For PCIe, for example, write transactions are posted and no response is returned when a write transaction is discarded. If the faulting transaction is a read then the device expects a completion. The IO bridge may provide a completion to the device. The data, if returned, in such completion is implementation defined; usually it is a fixed value such as all 0 or all 1. A status code may be returned to the device in the completion to indicate this condition. For AXI, for example, the completion status is provided by SLVERR on RRESP (Read Data channel). For PCIe, for example, the completion status field may be set to "Unsupported Request" (UR) or "Completer Abort" (CA).

In latest spec chapter 4.2. The process of hart mtt table walk is listed and what exception should be reported are listed too(although poisoned data is not considered here). However, for iomtt, things are different for handling access fault or poisoned data or reserved bits, is it possible to add some descriptions to clarify these situations in spec?

[ved-rivos]

However, for iomtt, things are different for handling access fault or poisoned data or reserved bits, is it possible to add some descriptions to clarify these situations in spec?

See #87

[rsahita]

this PR #87 is now merged.