| Message ID | 20190403034358.21999-2-richard.henderson@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tcg: Add CPUClass::tlb_fill | expand |
On Wed, 3 Apr 2019 at 10:46, Richard Henderson <richard.henderson@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.henderson@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
On 4/3/19 11:59 AM, Peter Maydell wrote: >> +#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 ? Hmm, you're right, this should test something else. I'll drop this for now... r~
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 + /* Convert forcefully to guest address space, invalid addresses are still valid segv ones */ address = h2g_nocheck(address);
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.henderson@linaro.org> --- accel/tcg/user-exec.c | 9 +++++++++ 1 file changed, 9 insertions(+)