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

[Peter Maydell]

On 9 February 2017 at 23:32, Richard Henderson <address@hidden> wrote:
> On 02/10/2017 07:58 AM, Peter Maydell wrote:
>> I use the M profile unassigned_access hook to implement
>> the "high addresses are magic, but only if you're in
>> Handler mode" behaviour. So for Thread mode I want the
>> default handling. You could argue that this is kind
>> of abusing the hook, though.
>
>
> I'm surprised you don't assign those high addresses to a magic device to
> handle that sort of magic.  Then they wouldn't be "unassigned".

We used to do that, but removed it in commit 542b3478a0 recently,
because it's a nasty hack. There really isn't a device there
(let alone a block of RAM). Among other things, reads and
writes aren't supposed to be magic, only executes and only
if the CPU is in a particular state. At least using the
unassigned_access hook keeps weird CPU behaviour in the
CPU and doesn't let it leak out into the system model.

(The proper non-hacky approach to this would be to do what
the spec says we should and make the branch instruction
itself behave differently if the register being branched to
has the magic value. But that would slow down branches
generally.)

>> Microblaze returns from the hook in the case where the
>> processor version register bit says "this CPU doesn't
>> generate exceptions for instruction/data aborts".
>> Since it looks like you can have a CPU config that
>> chooses to generate an exception for insn abort
>> but not data abort (or vice-versa), this looks like
>> a valid case for allowing the hook to return (you
>> need the hook for the case which you want to have
>> throw exceptions, but it gets called for the other
>> case too and needs to be able to say "nope" there).
>
>
> If the cpu doesn't implement aborts, then the processor must provide some
> default value for the memory return.  But the code path along which a return
> happens does not allow for data to be read.  We would need to expand the
> hook definition for this.

Yeah; at the moment the assumption is the cpu is ok with
qemu's generic default of RAZ/WI.

thanks
-- PMM