On Tue, 16 Jan 2024 at 14:50, Jonathan Cameron
<jonathan.came...@huawei.com> wrote:
>
> On Tue, 16 Jan 2024 13:20:33 +0000
> Peter Maydell <peter.mayd...@linaro.org> wrote:
> > Bisecting to this patch is a bit weird because at this point
> > in the series emulation of FEAT_NV2 should be disabled and
> > the code being added should never be used. You could put
> > an assert(0) into the code in translate-a64.c before the
> > call to syn_data_abort_vncr() and in arm_deliver_fault()
> > assert(!is_vncr) to confirm that we're not somehow getting
> > into this code for some non-FEAT_NV2 situation, I guess.
>
> Not that, but surprisingly is_vncr == true.
> in arm_deliver_fault()
>
> Frigging that to be false gets me up and running. I'll see
> if I can figure out why it is set.
I don't know if this is the cause, but looking again at the
line that sets is_vncr I see at least one obvious bug:
bool is_vncr = (mmu_idx != MMU_INST_FETCH) &&
(env->exception.syndrome & ARM_EL_VNCR);
is testing the wrong variable -- the first part
of the condition should be "access_type != MMU_INST_FETCH".
If you fix that does the failure go away ?
Yay for C and its very sloppy typing :-/
-- PMM
