qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Loading image/elf to cpu that has different not system


From: Marcin Krzemiński
Subject: Re: [Qemu-devel] Loading image/elf to cpu that has different not system memory address space
Date: Wed, 30 Sep 2015 07:18:41 +0200


2015-09-30 0:59 GMT+02:00 Peter Maydell <address@hidden>:
On 29 September 2015 at 23:40, Alistair Francis <address@hidden> wrote:
> On Thu, Sep 24, 2015 at 11:58 AM, mar.krzeminski
> <address@hidden> wrote:
>>
>>
>> W dniu 24.09.2015 o 20:38, Peter Crosthwaite pisze:
>>
>>> On Thu, Sep 24, 2015 at 10:14 AM, mar.krzeminski
>>> <address@hidden> wrote:
>>>> Today I stacked on other interesting think - and I do not want to spam
>>>> this
>>>> list - it is hack in cortex-m3
>>>> from armv7m.
>>>>
>>>>      /* Hack to map an additional page of ram at the top of the address
>>>>         space.  This stops qemu complaining about executing code outside
>>>> RAM
>>>>         when returning from an exception.  */
>>>>      memory_region_init_ram(hack, NULL, "armv7m.hack", 0x1000,
>>>> &error_abort);

>> Then took me a while to understand why qemu crash while serving M3 exception
>> because I haven't took this hack :)
>
> It sounds like you figured out why it's there. From memory it is to
> handle an exception, because the guest would just to a really high
> memory area and if there is no memory there QEMU will throw an error.

Sort of. This is for the exception-return mechanism, which on
M-profile works by having the function-return instructions
special-case attempts to "return" to addresses 0xfffffffx, which
should do exception return semantics. QEMU's implementation
handles this by treating "attempt to execute at 0xfffffff0"
specially in the translator (we generate EXCP_EXCEPTION_EXIT).
For this to work we have to have some fake RAM at that address.

This isn't actually an architecturally correct way to do it,
because the architecture says that you should only get the
special exception-return behaviour if you use the right
instructions to return to one of the magic addresses. If
you just try to branch into those addresses you should
get some kind of fault instead.

However, like many things in our M-profile implementation,
it sort of works and nobody has cared enough about M-profile
to try to clean it up. (An efficient implementation of the
right behaviour could be a bit tricky.)

thanks
-- PMM
I have at 0xfffffff0 real memory now (with aliasing to lower memory address).
Does it mean that qemu might try to execute some instructions from there?

Regards,
Marcin

reply via email to

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