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

[Richard Henderson <rth@twiddle.net>]

On 02/10/2017 07:58 AM, Peter Maydell wrote:
> On 9 February 2017 at 20:03, Richard Henderson <rth@twiddle.net> wrote:
>> On 02/09/2017 11:31 AM, Peter Maydell wrote:
>>> Review from somebody who understands how the unassigned_access
>>> hooks are supposed to work appreciated.
>
>> 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.
>
> 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".

> 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.

> The sparc code is too complicated for me to be able
> to judge whether its non-longjmping codepaths are
> valid or bugs.

I argued with Artyom that (at least) the sparc64 return code path is wrong. 
But I have no idea what the real cpu does for that case.


r~