Re: [PATCH 27/35] target/arm: Report VNCR_EL2 based faults correctly

[Jonathan Cameron via <qemu-arm@nongnu.org>]

On Tue, 16 Jan 2024 13:20:33 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Tue, 16 Jan 2024 at 13:09, Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > On Mon, 18 Dec 2023 11:32:57 +0000
> > Peter Maydell <peter.maydell@linaro.org> wrote:
> >  
> > > If FEAT_NV2 redirects a system register access to a memory offset
> > > from VNCR_EL2, that access might fault.  In this case we need to
> > > report the correct syndrome information:
> > >  * Data Abort, from same-EL
> > >  * no ISS information
> > >  * the VNCR bit (bit 13) is set
> > >
> > > and the exception must be taken to EL2.
> > >
> > > Save an appropriate syndrome template when generating code; we can
> > > then use that to:
> > >  * select the right target EL
> > >  * reconstitute a correct final syndrome for the data abort
> > >  * report the right syndrome if we take a FEAT_RME granule protection
> > >    fault on the VNCR-based write
> > >
> > > Note that because VNCR is bit 13, we must start keeping bit 13 in
> > > template syndromes, by adjusting ARM_INSN_START_WORD2_SHIFT.
> > >
> > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>  
> >
> > Hi Peter,
> >
> > I'm getting an unhelpful crash on calling init in a guest
> > running on top of an a76 emulated host with virtualization turned on.
> >
> > Run /sbin/init as init process
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
> > CPU: 1 PID: 1 Comm: init Not tainted 6.7.0+ #1119
> > Hardware name: linux,dummy-virt (DT)
> > Call trace:
> >  dump_backtrace+0xa0/0x128
> >  show_stack+0x20/0x38
> >  dump_stack_lvl+0x48/0x60
> >  dump_stack+0x18/0x28
> >  panic+0x380/0x3c0
> >  do_exit+0x89c/0x9a0
> >  do_group_exit+0x3c/0xa0
> >  get_signal+0x968/0x970
> >  do_notify_resume+0x21c/0x1460
> >  el0_ia+0xa0/0xb0
> >  el0t_64_sync_handler+0xd0/0x130
> >  el0t_64_sync+0x190/0x198
> > SMP: stopping secondary CPUs
> > Kernel Offset: 0x2a8c93a00000 from 0xffff800080000000
> > PHYS_OFFSET: 0xffff82f980000000
> > CPU features: 0x0,00000001,7002014a,2101720b
> > Memory Limit: none
> > ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 ]---
> >
> > Upstream kernel as of yesterday.  Nothing particular 'exciting' in the
> > configurations. Not attempting to use Nested virt.
> > -M virt,gic-version=3,virtualization=true
> > -cpu cortex-a76 (happens with max as well but switched to a76 for testing
> > to reduce possible sources of problems).
> >
> > Doesn't happen if single cpu in the guest, or if using gic v2 in both.
> >
> > Bisection points at this patch - so far no idea why but I've only
> > just started digging into this.  
> 
> 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.

J
> 
> thanks
> -- PMM