On 7/29/22 07:31, Peter Maydell wrote:
On Tue, 28 Jun 2022 at 05:54, Richard Henderson
<[email protected]> wrote:
We were reporting unconditional success for these functions;
pass on any failure from cpu_memory_rw_debug.
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
So, this commit makes us check the cpu_memory_rw_debug()
return value in the softmmu_lock_user() function; but Coverity
points out (CID 1490294) that we still aren't checking the
return value from when we call it in softmmu_unlock_user()...
What, if anything, should we do about that? In particular,
I think that for semihosting calls that write to guest memory,
if the guest passes us a pointer to read-only memory we're
not going to find out about that until unlock time.
Not even then, because address_space_write_rom will in fact write to rom, nevermind
virtual page permissions. Moreover, there are no failure conditions from
address_space_write_rom. It skips non-{ram,rom} and always returns OK.
It's probable that we should be using cpu_memory_rw_debug at all, but should be using a
higher-level interface, something that (1) checks the virtual page permissions and (2)
probably rejects semihosting to mmio.
But in the short term, I think we can just ignore the warning.
r~