qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] cputlb: Don't assume do_unassigned_access() nev


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] cputlb: Don't assume do_unassigned_access() never returns
Date: Thu, 9 Feb 2017 12:03:11 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 02/09/2017 11:31 AM, Peter Maydell wrote:
In get_page_addr_code(), if the guest PC doesn't correspond to RAM
then we currently run the CPU's do_unassigned_access() hook if it has
one, and otherwise we give up and exit QEMU with a more-or-less
useful message.  This code assumes that the do_unassigned_access hook
will never return, because if it does then we'll plough on attempting
to use a non-RAM TLB entry to get a RAM address and will abort() in
qemu_ram_addr_from_host_nofail().  Unfortunately some CPU
implementations of this hook do return: Microblaze, SPARC and the ARM
v7M.

Change the code to call report_bad_exec() if the hook returns, as
well as if it didn't have one.  This means we can tidy it up to use
the cpu_unassigned_access() function which wraps the "get the CPU
class and call the hook if it has one" work, since we aren't trying
to distinguish "no hook" from "hook existed and returned" any more.

This brings the handling of this hook into line with the handling
used for data accesses, where "hook returned" is treated the
same as "no hook existed" and gets you the default behaviour.

Signed-off-by: Peter Maydell <address@hidden>
---
Review from somebody who understands how the unassigned_access
hooks are supposed to work appreciated.

 cputlb.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

The unassigned_access hook was (unfortunately) designed after the unaligned_access hook. The later *can* usefully return to indicate that the cpu bit that enforces alignment traps is off.

Any unassigned_access hook that doesn't longjmp could be considered buggy.

Reviewed-by: Richard Henderson <address@hidden>


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]