On Wed, 3 Apr 2019 at 10:46, Richard Henderson <richard.hender...@linaro.org> wrote: > > For this combination, we can tell whether or not the address > being accessed is within the 4GB range that is accessible by > the guest. Otherwise the fault must be elsewhere in qemu, > accessing qemu data structures. > > Signed-off-by: Richard Henderson <richard.hender...@linaro.org> > --- > accel/tcg/user-exec.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c > index 0789984fe6..fa9380a380 100644 > --- a/accel/tcg/user-exec.c > +++ b/accel/tcg/user-exec.c > @@ -143,6 +143,15 @@ static inline int handle_cpu_signal(uintptr_t pc, > siginfo_t *info, > } > } > > + /* > + * For a 32-bit guest on a 64-bit host, the set of addresses that we > + * access on behalf of the guest is constrained. Anything outside > + * that range is a bug elsewhere in QEMU. > + */ > +#if TARGET_LONG_BITS == 32 && HOST_LONG_BITS == 64 > + g_assert(h2g_valid(address)); > +#endif
I'm not sure this is right. h2g_valid() will check whether the guest address is below GUEST_ADDR_MAX. For architectures which set TARGET_VIRT_ADDR_SPACE_BITS to something less than 32 there are address values which aren't h2g_valid() but which we still want to cause a guest exception rather than asserting, aren't there ? thanks -- PMM