[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 11/16] target/arm: Update contiguous first-fault and no-fault
Re: [PATCH 11/16] target/arm: Update contiguous first-fault and no-fault loads
Thu, 16 Apr 2020 15:15:04 +0100
On Wed, 11 Mar 2020 at 06:44, Richard Henderson
> With sve_cont_ldst_pages, the differences between first-fault and no-fault
> are minimal, so unify the routines. With cpu_probe_watchpoint, we are able
> to make progress through pages with TLB_WATCHPOINT set when the watchpoint
> does not actually fire.
> Signed-off-by: Richard Henderson <address@hidden>
> - * Perform one normal read, which will fault or not.
> - * But it is likely to bring the page into the tlb.
> + * 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 don't think you can assume this; for instance a QEMU 'romd'
device might reasonably be mapped as Normal memory but currently
be in "send all accesses to my read/write functions" mode.
> + *
> + * Similarly, CPU_BP breakpoints would raise exceptions, and so
> + * return (UNKNOWN, FAULT). For simplicity, we consider gdb and
> + * architectural breakpoints the same.
- Re: [PATCH 11/16] target/arm: Update contiguous first-fault and no-fault loads,
Peter Maydell <=