Version 7 has one more tweak to the vhe tlb flushing
that Peter asked for.  All patches have reviews.


r~


Alex Bennée (1):
  target/arm: check TGE and E2H flags for EL0 pauth traps

Richard Henderson (40):
  target/arm: Define isar_feature_aa64_vh
  target/arm: Enable HCR_E2H for VHE
  target/arm: Add CONTEXTIDR_EL2
  target/arm: Add TTBR1_EL2
  target/arm: Update CNTVCT_EL0 for VHE
  target/arm: Split out vae1_tlbmask
  target/arm: Split out alle1_tlbmask
  target/arm: Simplify tlb_force_broadcast alternatives
  target/arm: Rename ARMMMUIdx*_S12NSE* to ARMMMUIdx*_E10_*
  target/arm: Rename ARMMMUIdx_S2NS to ARMMMUIdx_Stage2
  target/arm: Rename ARMMMUIdx_S1NSE* to ARMMMUIdx_Stage1_E*
  target/arm: Rename ARMMMUIdx_S1SE[01] to ARMMMUIdx_SE10_[01]
  target/arm: Rename ARMMMUIdx*_S1E3 to ARMMMUIdx*_SE3
  target/arm: Rename ARMMMUIdx_S1E2 to ARMMMUIdx_E2
  target/arm: Recover 4 bits from TBFLAGs
  target/arm: Expand TBFLAG_ANY.MMUIDX to 4 bits
  target/arm: Rearrange ARMMMUIdxBit
  target/arm: Tidy ARMMMUIdx m-profile definitions
  target/arm: Reorganize ARMMMUIdx
  target/arm: Add regime_has_2_ranges
  target/arm: Update arm_mmu_idx for VHE
  target/arm: Update arm_sctlr for VHE
  target/arm: Update aa64_zva_access for EL2
  target/arm: Update ctr_el0_access for EL2
  target/arm: Add the hypervisor virtual counter
  target/arm: Update timer access for VHE
  target/arm: Update define_one_arm_cp_reg_with_opaque for VHE
  target/arm: Add VHE system register redirection and aliasing
  target/arm: Add VHE timer register redirection and aliasing
  target/arm: Flush tlb for ASID changes in EL2&0 translation regime
  target/arm: Flush tlbs for E2&0 translation regime
  target/arm: Update arm_phys_excp_target_el for TGE
  target/arm: Update {fp,sve}_exception_el for VHE
  target/arm: Update get_a64_user_mem_index for VHE
  target/arm: Update arm_cpu_do_interrupt_aarch64 for VHE
  target/arm: Enable ARMv8.1-VHE in -cpu max
  target/arm: Move arm_excp_unmasked to cpu.c
  target/arm: Pass more cpu state to arm_excp_unmasked
  target/arm: Use bool for unmasked in arm_excp_unmasked
  target/arm: Raise only one interrupt in arm_cpu_exec_interrupt

 target/arm/cpu-param.h     |    2 +-
 target/arm/cpu-qom.h       |    1 +
 target/arm/cpu.h           |  423 +++++--------
 target/arm/internals.h     |   73 ++-
 target/arm/translate.h     |    4 +-
 target/arm/cpu.c           |  162 ++++-
 target/arm/cpu64.c         |    1 +
 target/arm/debug_helper.c  |   50 +-
 target/arm/helper-a64.c    |    2 +-
 target/arm/helper.c        | 1211 +++++++++++++++++++++++++++---------
 target/arm/pauth_helper.c  |   14 +-
 target/arm/translate-a64.c |   47 +-
 target/arm/translate.c     |   74 ++-
 13 files changed, 1383 insertions(+), 681 deletions(-)

-- 
2.20.1

On Thu, 6 Feb 2020 at 10:54, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Version 7 has one more tweak to the vhe tlb flushing
> that Peter asked for.  All patches have reviews.
>
>



Applied to target-arm.next, thanks.

-- PMM

On Fri, 7 Feb 2020 11:52:46 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Thu, 6 Feb 2020 at 10:54, Richard Henderson
> <richard.henderson@linaro.org> wrote:
> >
> > Version 7 has one more tweak to the vhe tlb flushing
> > that Peter asked for.  All patches have reviews.
> >
> >  
> 
> 
> 
> Applied to target-arm.next, thanks.

Hi Peter / Richard.

Just wondering if there are any known issues with this?

I'm trying to test with mainline kernel 5.6, and the qemu rc0.
Host emulating 4 core cpu=max,virtualization=on, guest 1 core.

I get one of those lovely init died messages.
(copy typed between screens)

Run /sbin/init as init process
Kernel panic - not synching: Attempted to kill init! exitcode =0x0000000b

Nothing obvious in the trace for why.

Same kernel / image / setup etc works fine when tested with a real
VHE supporting machine as the host (kunpeng920).

Also fine running as a guest inside the emulated host without kvm.

This is a bit too much of a case of Russian dolls so I'm not even sure
how to get any useful debug information.

Thanks,

Jonathan


> 
> -- PMM
> 

On Tue, 31 Mar 2020 16:33:24 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Fri, 7 Feb 2020 11:52:46 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> > On Thu, 6 Feb 2020 at 10:54, Richard Henderson
> > <richard.henderson@linaro.org> wrote:  
> > >
> > > Version 7 has one more tweak to the vhe tlb flushing
> > > that Peter asked for.  All patches have reviews.
> > >
> > >    
> > 
> > 
> > 
> > Applied to target-arm.next, thanks.  
> 
> Hi Peter / Richard.
> 
> Just wondering if there are any known issues with this?
> 
> I'm trying to test with mainline kernel 5.6, and the qemu rc0.
> Host emulating 4 core cpu=max,virtualization=on, guest 1 core.
> 
> I get one of those lovely init died messages.
> (copy typed between screens)
> 
> Run /sbin/init as init process
> Kernel panic - not synching: Attempted to kill init! exitcode =0x0000000b
> 
> Nothing obvious in the trace for why.
> 
> Same kernel / image / setup etc works fine when tested with a real
> VHE supporting machine as the host (kunpeng920).

Another data point.  All seems fine with cpu=cortex-a57,virtualization=on
but obviously without VHE.

Thanks to Salil for pointing out I'd not run this combination.

Jonathan

> 
> Also fine running as a guest inside the emulated host without kvm.
> 
> This is a bit too much of a case of Russian dolls so I'm not even sure
> how to get any useful debug information.
> 
> Thanks,
> 
> Jonathan
> 
> 
> > 
> > -- PMM
> >   
> 

On 3/31/20 8:33 AM, Jonathan Cameron wrote:
> Just wondering if there are any known issues with this?

Nope.  It works for me.
Can you give us any more details.


r~

On Tue, 31 Mar 2020 11:59:13 -0700
Richard Henderson <richard.henderson@linaro.org> wrote:

> On 3/31/20 8:33 AM, Jonathan Cameron wrote:
> > Just wondering if there are any known issues with this?  
> 
> Nope.  It works for me.
> Can you give us any more details.
> 

Unfortunately not a lot more to add.

I ran some sanity checks that it wasn't something else looking like an issue
in these patches.

All with 5.6 kernel and 5.0.0 rc0 qemu

1) sve=off but VHE still on. failed.
2) sve=off + VH bit not set. fine but obviously no VHE.
(dance with SVE required because of kernel checks for SVE before allowing
 no VHE kvm).
3) above tests run on mainline qemu just after VHE patches applied (just in case
   we have a regression from some other change).  No change.
4) EDK2 for the guest.  Synchronous exception. (works fine with no VHE)
0x00..05F9B2208

I do get an additional error sometimes such as the ld.so one here.

[   16.539375] Run /sbin/init as init process
Inconsistency detected by ld.so: rtld.c: 721: init_tls: Assertion `i == GL(dl_tls_max_dtv_idx)' failed!
[   17.780596] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[   17.847709] CPU: 0 PID: 1 Comm: init Not tainted 5.6.0 #356
[   17.897260] Hardware name: linux,dummy-virt (DT)
[   17.940007] Call trace:
[   17.962297]  dump_backtrace+0x0/0x190
[   17.993897]  show_stack+0x1c/0x28
[   18.022382]  dump_stack+0xb4/0xfc
[   18.050781]  panic+0x160/0x35c
[   18.077469]  do_exit+0x9a4/0xa08
[   18.105510]  do_group_exit+0x48/0xa8
[   18.136073]  __arm64_sys_exit_group+0x1c/0x20
[   18.173677]  el0_svc_common.constprop.0+0x70/0x168
[   18.218659]  do_el0_svc+0x28/0x88
[   18.247154]  el0_sync_handler+0x10c/0x180
[   18.281379]  el0_sync+0x140/0x180
[   18.310684] Kernel Offset: 0x2a67dcc00000 from 0xffff800010000000
[   18.362474] PHYS_OFFSET: 0xfffff79400000000
[   18.398314] CPU features: 0x40012,20c0a238
[   18.433416] Memory Limit: none
[   18.463648] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 ]---


Jonathan


> 
> r~

On Wed, 1 Apr 2020 11:45:22 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Tue, 31 Mar 2020 11:59:13 -0700
> Richard Henderson <richard.henderson@linaro.org> wrote:
> 
> > On 3/31/20 8:33 AM, Jonathan Cameron wrote:  
> > > Just wondering if there are any known issues with this?    
> > 
> > Nope.  It works for me.
> > Can you give us any more details.
> >   
> 
> Unfortunately not a lot more to add.
> 
> I ran some sanity checks that it wasn't something else looking like
> an issue in these patches.
> 
> All with 5.6 kernel and 5.0.0 rc0 qemu
> 
> 1) sve=off but VHE still on. failed.
> 2) sve=off + VH bit not set. fine but obviously no VHE.
> (dance with SVE required because of kernel checks for SVE before
> allowing no VHE kvm).
> 3) above tests run on mainline qemu just after VHE patches applied
> (just in case we have a regression from some other change).  No
> change. 4) EDK2 for the guest.  Synchronous exception. (works fine
> with no VHE) 0x00..05F9B2208

This one may be something since fixed in edk2.  I did a fresh build
of the current tree and it goes away.

> 
> I do get an additional error sometimes such as the ld.so one here.
> 
> [   16.539375] Run /sbin/init as init process
> Inconsistency detected by ld.so: rtld.c: 721: init_tls: Assertion `i
> == GL(dl_tls_max_dtv_idx)' failed! [   17.780596] Kernel panic - not
> syncing: Attempted to kill init! exitcode=0x00007f00 [   17.847709]
> CPU: 0 PID: 1 Comm: init Not tainted 5.6.0 #356 [   17.897260]
> Hardware name: linux,dummy-virt (DT) [   17.940007] Call trace:
> [   17.962297]  dump_backtrace+0x0/0x190
> [   17.993897]  show_stack+0x1c/0x28
> [   18.022382]  dump_stack+0xb4/0xfc
> [   18.050781]  panic+0x160/0x35c
> [   18.077469]  do_exit+0x9a4/0xa08
> [   18.105510]  do_group_exit+0x48/0xa8
> [   18.136073]  __arm64_sys_exit_group+0x1c/0x20
> [   18.173677]  el0_svc_common.constprop.0+0x70/0x168
> [   18.218659]  do_el0_svc+0x28/0x88
> [   18.247154]  el0_sync_handler+0x10c/0x180
> [   18.281379]  el0_sync+0x140/0x180
> [   18.310684] Kernel Offset: 0x2a67dcc00000 from 0xffff800010000000
> [   18.362474] PHYS_OFFSET: 0xfffff79400000000
> [   18.398314] CPU features: 0x40012,20c0a238
> [   18.433416] Memory Limit: none
> [   18.463648] ---[ end Kernel panic - not syncing: Attempted to kill
> init! exitcode=0x00007f00 ]---

Seems I can get away with an initrd, but not a qcow2 based disk image.

Not that this necessarily helps much with working out what is going
wrong!

Jonathan

> 
> 
> Jonathan
> 
> 
> > 
> > r~  
>