What is the difference between "access fault" and "page fault" ?

[merle wang]

I found them to be similar, I want to know the difference between them.

Instruction access fault -> Instruction page fault
Load access fault -> Load page fault
Store/AMO access fault -> Store/AMO page fault

Looking forward to your reply ! ! !

WangXiang

[Samuel Falvo II]

I could be mistaken, but I believe "access faults" are generated by
address decoding circuitry to detect accesses to non-existent spans of
memory. Without these "bus errors", so to speak, the processor could
end up deadlocking waiting for something to respond that isn't
actually there.

A page fault is a problem discovered by the MMU *before* the access is
even pushed out to the bus.

I seem to recall that the difference between access and page faults
are discussed in the section on physical memory protection.


--
Samuel A. Falvo II

[Andrew Waterman]

On Thu, Aug 2, 2018 at 10:44 PM Samuel Falvo II <sam....@gmail.com> wrote:

On Thu, Aug 2, 2018 at 10:01 PM merle wang <merl...@gmail.com> wrote:
> I found them to be similar, I want to know the difference between them.
>
> Instruction access fault -> Instruction page fault
> Load access fault -> Load page fault
> Store/AMO access fault -> Store/AMO page fault
>
> Looking forward to your reply ! ! !

I could be mistaken, but I believe "access faults" are generated by
address decoding circuitry to detect accesses to non-existent spans of
memory.  Without these "bus errors", so to speak, the processor could
end up deadlocking waiting for something to respond that isn't
actually there.

A page fault is a problem discovered by the MMU *before* the access is
even pushed out to the bus.

Yeah - page faults are only ever raised by the virtual-memory mechanisms.

I seem to recall that the difference between access and page faults
are discussed in the section on physical memory protection.


--
Samuel A. Falvo II

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsomYXich58FbHJSbmoPF%2B5e79N9PZNxM_mY491SSHvkigA%40mail.gmail.com.

[Rishiyur Nikhil]

>    I could be mistaken, but I believe "access faults" are generated by
>    address decoding circuitry to detect accesses to non-existent spans of memory.

Or, more generally, any issue in the "bus".

Examples: parity/ECC errors, physical memory protection errors, timeouts, ...

On Fri, Aug 3, 2018 at 7:18 AM, Andrew Waterman <and...@sifive.com> wrote:

On Thu, Aug 2, 2018 at 10:44 PM Samuel Falvo II <sam....@gmail.com> wrote:

On Thu, Aug 2, 2018 at 10:01 PM merle wang <merl...@gmail.com> wrote:
> I found them to be similar, I want to know the difference between them.
>
> Instruction access fault -> Instruction page fault
> Load access fault -> Load page fault
> Store/AMO access fault -> Store/AMO page fault
>
> Looking forward to your reply ! ! !

I could be mistaken, but I believe "access faults" are generated by
address decoding circuitry to detect accesses to non-existent spans of
memory.  Without these "bus errors", so to speak, the processor could
end up deadlocking waiting for something to respond that isn't
actually there.

A page fault is a problem discovered by the MMU *before* the access is
even pushed out to the bus.

Yeah - page faults are only ever raised by the virtual-memory mechanisms.

I seem to recall that the difference between access and page faults
are discussed in the section on physical memory protection.


--
Samuel A. Falvo II

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsomYXich58FbHJSbmoPF%2B5e79N9PZNxM_mY491SSHvkigA%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0CfK5HCO_j6UugqJYLtTO_5wxwAwgTOfdAt%3DAnhec0Wyw%40mail.gmail.com.

[Michael Clark]

On 7/08/2018, at 3:25 AM, Rishiyur Nikhil <nik...@bluespec.com> wrote:

>    I could be mistaken, but I believe "access faults" are generated by
>    address decoding circuitry to detect accesses to non-existent spans of memory.

Or, more generally, any issue in the "bus".

Examples: parity/ECC errors, physical memory protection errors, timeouts, ..

Would it be beneficial to distinguish the cause codes? e.g. a timeout could be retried.

The current common case where one would want compatibility is “address not mapped”. Also for PMP, one would not want a lower privilege level to distinguish a PMP access fault from an “address not mapped” fault.

However the question is would having more detail for the fault e.g. timeout, corruption (ECC/parity) or any other cause values, be useful for the OS? I think so. The OS function/remediation for faults, to some degree is limited by the information given in the fault. e.g. a timeout is distinct from not mapped. e.g. can’t right now vs never. Some languages do not have “No” for example and thus distinguish “can not / can’t” and “will not / won’t”.

On distinguishing causes more precisely, I had raised an issue on the spec to have cause codes for TSR (Trap SRET), TVM (Trap Virtual Memory) and TW (Trap Wait For Interrupt). The rationale is that it saves the Hypervisor from needing to parse the instruction at the faulting address , similarly to a load/store/fetch access fault not needing to parse the instruction at epc to distinguish the fault type. A fetch fault of course would cause a double fault trying to read the instruction, so it’s necessary.

To not use up too many cause codes for the TSR/TVM/TW case, (for the reason of delegation bits), we could have one “Supervisor Exit” cause code and have subcodes in mtval, the first 3 being those stated, ideally starting at 1.

If it were agreed in principle, to distinguish causes, I don’t mind making a PR for some candidate wording for these supervisor exits (of course writing in the spec vernacular and style).

[Andrew Waterman]

On Mon, Aug 6, 2018 at 1:13 PM, Michael Clark <michae...@mac.com> wrote:
>
>
> On 7/08/2018, at 3:25 AM, Rishiyur Nikhil <nik...@bluespec.com> wrote:
>
>> I could be mistaken, but I believe "access faults" are generated by
>> address decoding circuitry to detect accesses to non-existent spans of
>> memory.
>
> Or, more generally, any issue in the "bus".
> Examples: parity/ECC errors, physical memory protection errors, timeouts, ..
>
>
> Would it be beneficial to distinguish the cause codes? e.g. a timeout could
> be retried.

This is perhaps better handled by a higher-level mechanism, e.g.,
software responds to the access exception by querying the bus
controller about what actually went wrong, then retries the access if
appropriate.

[Allen Baum]

You can distinguish faults from interrupts here.
Uncorrectable errors that are synchronous can be handled with faults. Sometimes they can't be attributed to any particular instruction ( e.g. some line missed in the cache, so another line was evicted. Since the evicted line address has no connection with the instruction that cache missed, it's effectively asynchronous and uses interrupts) (NMI most likely) .
Timeouts that retry are correctable.
A well designed system doesn't need to trap, but should log the error somehow, possibly just incrementing an error counter. If that counter overflows, you may want to interrupt- later- and at that point the handler can poll all the counters and error cause logs to find out why.

-Allen

> On Aug 6, 2018, at 1:26 PM, Andrew Waterman <and...@sifive.com> wrote:
>
>> On Mon, Aug 6, 2018 at 1:13 PM, Michael Clark <michae...@mac.com> wrote:
>>
>>
>>> On 7/08/2018, at 3:25 AM, Rishiyur Nikhil <nik...@bluespec.com> wrote:
>>>
>>> I could be mistaken, but I believe "access faults" are generated by
>>> address decoding circuitry to detect accesses to non-existent spans of
>>> memory.
>>
>> Or, more generally, any issue in the "bus".
>> Examples: parity/ECC errors, physical memory protection errors, timeouts, ..
>>
>>
>> Would it be beneficial to distinguish the cause codes? e.g. a timeout could
>> be retried.
>
> This is perhaps better handled by a higher-level mechanism, e.g.,
> software responds to the access exception by querying the bus
> controller about what actually went wrong, then retries the access if
> appropriate.
>
>>
>> The current common case where one would want compatibility is “address not
>> mapped”. Also for PMP, one would not want a lower privilege level to
>> distinguish a PMP access fault from an “address not mapped” fault.
>>
>> However the question is would having more detail for the fault e.g. timeout,
>> corruption (ECC/parity) or any other cause values, be useful for the OS? I
>> think so. The OS function/remediation for faults, to some degree is limited

> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0BzaD-TE%3DeP1t1nRCART4rhQ1sdWpLXP-LzpzP6k3ZyMw%40mail.gmail.com.