From: Richard Henderson <richard.henderson@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>, QEMU Developers <qemu-devel@nongnu.org>
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 [thread overview]
Message-ID: <d148806b-c7f1-fefc-bfb4-fcefb81ab509@linaro.org> (raw)
In-Reply-To: <CAFEAcA-iqrEi_wQ+mBN1NtrEKq3uDYPoDunqW5e9KV6ivz3-SQ@mail.gmail.com>
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~
next prev parent reply other threads:[~2020-04-27 16:52 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 4:32 [PATCH v3 00/18] target/arm: sve load/store improvements Richard Henderson
2020-04-22 4:32 ` [PATCH v3 01/18] exec: Add block comments for watchpoint routines Richard Henderson
2020-04-27 9:27 ` Peter Maydell
2020-04-22 4:32 ` [PATCH v3 02/18] exec: Fix cpu_watchpoint_address_matches address length Richard Henderson
2020-04-27 9:28 ` Peter Maydell
2020-04-22 4:32 ` [PATCH v3 03/18] accel/tcg: Add block comment for probe_access Richard Henderson
2020-04-22 4:32 ` [PATCH v3 04/18] accel/tcg: Add probe_access_flags Richard Henderson
2020-04-27 10:48 ` Peter Maydell
2020-04-27 16:00 ` Richard Henderson
2020-05-04 9:39 ` Peter Maydell
2020-04-22 4:32 ` [PATCH v3 05/18] accel/tcg: Add endian-specific cpu_{ld, st}* operations Richard Henderson
2020-04-27 9:46 ` Peter Maydell
2020-04-22 4:32 ` [PATCH v3 06/18] target/arm: Use cpu_*_data_ra for sve_ldst_tlb_fn Richard Henderson
2020-04-27 10:51 ` Peter Maydell
2020-04-22 4:32 ` [PATCH v3 07/18] target/arm: Drop manual handling of set/clear_helper_retaddr Richard Henderson
2020-04-22 4:32 ` [PATCH v3 08/18] target/arm: Add sve infrastructure for page lookup Richard Henderson
2020-04-27 11:00 ` Peter Maydell
2020-04-22 4:33 ` [PATCH v3 09/18] target/arm: Adjust interface of sve_ld1_host_fn Richard Henderson
2020-04-22 4:33 ` [PATCH v3 10/18] target/arm: Use SVEContLdSt in sve_ld1_r Richard Henderson
2020-04-22 4:33 ` [PATCH v3 11/18] target/arm: Handle watchpoints " Richard Henderson
2020-04-22 4:33 ` [PATCH v3 12/18] target/arm: Use SVEContLdSt for multi-register contiguous loads Richard Henderson
2020-04-22 4:33 ` [PATCH v3 13/18] target/arm: Update contiguous first-fault and no-fault loads Richard Henderson
2020-04-27 11:03 ` Peter Maydell
2020-04-27 16:16 ` Richard Henderson
2020-04-27 16:32 ` Peter Maydell
2020-04-27 16:45 ` Richard Henderson [this message]
2020-04-27 18:38 ` Peter Maydell
2020-04-28 15:02 ` Richard Henderson
2020-04-22 4:33 ` [PATCH v3 14/18] target/arm: Use SVEContLdSt for contiguous stores Richard Henderson
2020-04-22 4:33 ` [PATCH v3 15/18] target/arm: Reuse sve_probe_page for gather first-fault loads Richard Henderson
2020-04-22 4:33 ` [PATCH v3 16/18] target/arm: Reuse sve_probe_page for scatter stores Richard Henderson
2020-04-22 4:33 ` [PATCH v3 17/18] target/arm: Reuse sve_probe_page for gather loads Richard Henderson
2020-04-22 4:33 ` [PATCH v3 18/18] target/arm: Remove sve_memopidx Richard Henderson
2020-04-22 5:37 ` [PATCH v3 00/18] target/arm: sve load/store improvements no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d148806b-c7f1-fefc-bfb4-fcefb81ab509@linaro.org \
--to=richard.henderson@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).