[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 13/18] target/arm: Update contiguous first-fault and no-fa
From: |
Richard Henderson |
Subject: |
Re: [PATCH v3 13/18] target/arm: Update contiguous first-fault and no-fault loads |
Date: |
Mon, 27 Apr 2020 09:45:34 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 4/27/20 9:32 AM, Peter Maydell wrote:
>>>> + * From this point on, all memory operations are MemSingleNF.
>>>> + *
>>>> + * Per the MemSingleNF pseudocode, a no-fault load from Device memory
>>>> + * must not actually hit the bus -- it returns (UNKNOWN, FAULT)
>>>> instead.
>>>> + * If you map non-RAM with Normal memory attributes and do a NF
>>>> + * load then it should access the bus -- but doing so is illegal.
>>>> + *
>>>> + * While we do not have access to the memory attributes from the PTE
>>>> + * to tell Device memory from Normal memory, we can validly assume
>>>> that
>>>> + * non-RAM has been mapped as Device memory. Thus we indicate fault
>>>> + * on all MMIO.
>>>
>>> I still don't understand why this is right. All non-RAM is MMIO
>>> but not all MMIO is non-RAM; so you might have something that's
>>> MMIO (at least for the moment) and has been mapped Normal. That
>>> shouldn't fault.
>>
>> Everything that must go through the slow path has TLB_MMIO set.
>
> Yes. But not everything that goes through the slow path is Device memory.
> We can (should) fault on all accesses to Device memory, but we can't
> fault on all accesses that are slow-pathed, because some of them could
> be entirely valid Normal memory.
We *can* indicate fault from MemSingleNF for any reason whatsoever, or no
reason whatsoever.
> // Implementation may suppress NF load for any reason
> if ConstrainUnpredictableBool(Unpredictable_NONFAULT) then
> return (bits(8*size) UNKNOWN, TRUE);
What I'm trying to talk about above, is the third statement in MemSingleNF,
> // Non-fault load from Device memory must not be performed externally
> if memaddrdesc.memattrs.memtype == MemType_Device then
> return (bits(8*size) UNKNOWN, TRUE);
and the reason we can't actually test MemType_Device here.
If you have better wording for that, I'm all ears. But I don't think there's
an actual bug here.
r~
- [PATCH v3 08/18] target/arm: Add sve infrastructure for page lookup, (continued)
- [PATCH v3 08/18] target/arm: Add sve infrastructure for page lookup, Richard Henderson, 2020/04/22
- [PATCH v3 10/18] target/arm: Use SVEContLdSt in sve_ld1_r, Richard Henderson, 2020/04/22
- [PATCH v3 12/18] target/arm: Use SVEContLdSt for multi-register contiguous loads, Richard Henderson, 2020/04/22
- [PATCH v3 07/18] target/arm: Drop manual handling of set/clear_helper_retaddr, Richard Henderson, 2020/04/22
- [PATCH v3 14/18] target/arm: Use SVEContLdSt for contiguous stores, Richard Henderson, 2020/04/22
- [PATCH v3 13/18] target/arm: Update contiguous first-fault and no-fault loads, Richard Henderson, 2020/04/22
[PATCH v3 15/18] target/arm: Reuse sve_probe_page for gather first-fault loads, Richard Henderson, 2020/04/22
[PATCH v3 16/18] target/arm: Reuse sve_probe_page for scatter stores, Richard Henderson, 2020/04/22
[PATCH v3 18/18] target/arm: Remove sve_memopidx, Richard Henderson, 2020/04/22
[PATCH v3 11/18] target/arm: Handle watchpoints in sve_ld1_r, Richard Henderson, 2020/04/22
[PATCH v3 17/18] target/arm: Reuse sve_probe_page for gather loads, Richard Henderson, 2020/04/22
Re: [PATCH v3 00/18] target/arm: sve load/store improvements, no-reply, 2020/04/22