qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target/arm: Don't abort on M-profile exception


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] target/arm: Don't abort on M-profile exception return in linux-user mode
Date: Thu, 22 Aug 2019 10:02:55 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 8/22/19 6:15 AM, Peter Maydell wrote:
> The upshot of all this is that for linux-user mode we should never
> do any of the bx_excret magic, so the code change is simple.
> 
> This ought to be a weird corner case that only affects broken guest
> code (because Linux user processes should never be attempting to do
> exception returns or NS function returns), except that the code that
> assigns addresses in RAM for the process and stack in our linux-user
> code does not attempt to avoid this magic address range, so
> legitimate code attempting to return to a trampoline routine on the
> stack can fall into this case. This change fixes those programs,
> but we should also look at restricting the range of memory we
> use for M-profile linux-user guests to the area that would be
> real RAM in hardware.
> 
> Cc: address@hidden
> Reported-by: Christophe Lyon <address@hidden>
> Fixes: https://bugs.launchpad.net/qemu/+bug/1840922
> Signed-off-by: Peter Maydell <address@hidden>

Reviewed-by: Richard Henderson <address@hidden>

> I have no idea how we could achieve the "restrict addresses
> shown to guest for linux-user" mentioned in the last para:
> any suggestions?

I guess we'd want a new cpu hook, and change MAX_RESERVED_VA
from a macro into a function call.

Move the cpu_create() in linux-user/main.c up a few lines
before we default reserved_va for 64-bit hosts.

Move the check of the command-line setting of reserved_va
vs MAX_RESERVED_VA out from handle_arg_reserved_va to just
after the aforementioned default.

Seems plausible, anyway.


r~



reply via email to

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