On Thu, 23 Nov 2023 16:21:48 +0000, Miguel Luis <miguel.luis@xxxxxxxxxx> wrote: > > Hi Marc, > > On 21/11/2023 18:02, Marc Zyngier wrote: > > On Tue, 21 Nov 2023 16:49:52 +0000, > > Miguel Luis <miguel.luis@xxxxxxxxxx> wrote: > >> Hi Marc, > >> > >>> On 20 Nov 2023, at 12:09, Marc Zyngier <maz@xxxxxxxxxx> wrote: > >>> > >>> This is the 5th drop of NV support on arm64 for this year, and most > >>> probably the last one for this side of Christmas. > >>> > >>> For the previous episodes, see [1]. > >>> > >>> What's changed: > >>> > >>> - Drop support for the original FEAT_NV. No existing hardware supports > >>> it without FEAT_NV2, and the architecture is deprecating the former > >>> entirely. This results in fewer patches, and a slightly simpler > >>> model overall. > >>> > >>> - Reorganise the series to make it a bit more logical now that FEAT_NV > >>> is gone. > >>> > >>> - Apply the NV idreg restrictions on VM first run rather than on each > >>> access. > >>> > >>> - Make the nested vgic shadow CPU interface a per-CPU structure rather > >>> than per-vcpu. > >>> > >>> - Fix the EL0 timer fastpath > >>> > >>> - Work around the architecture deficiencies when trapping WFI from a > >>> L2 guest. > >>> > >>> - Fix sampling of nested vgic state (MISR, ELRSR, EISR) > >>> > >>> - Drop the patches that have already been merged (NV trap forwarding, > >>> per-MMU VTCR) > >>> > >>> - Rebased on top of 6.7-rc2 + the FEAT_E2H0 support [2]. > >>> > >>> The branch containing these patches (and more) is at [3]. As for the > >>> previous rounds, my intention is to take a prefix of this series into > >>> 6.8, provided that it gets enough reviewing. > >>> > >>> [1] https://lore.kernel.org/r/20230515173103.1017669-1-maz@xxxxxxxxxx > >>> [2] https://lore.kernel.org/r/20231120123721.851738-1-maz@xxxxxxxxxx > >>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv-6.8-nv2-only > >>> > >> While I was testing this with kvmtool for 5.16 I noted the following on dmesg: > >> > >> [ 803.014258] kvm [19040]: Unsupported guest sys_reg access at: 8129fa50 [600003c9] > >> { Op0( 3), Op1( 5), CRn( 1), CRm( 0), Op2( 2), func_read }, > >> > >> This is CPACR_EL12. > > CPACR_EL12 is redirected to VNCR[0x100]. It really shouldn't trap... > > > >> Still need yet to debug. > > Can you disassemble the guest around the offending PC? > > [ 1248.686350] kvm [7013]: Unsupported guest sys_reg access at: 812baa50 [600003c9] > { Op0( 3), Op1( 5), CRn( 1), CRm( 0), Op2( 2), func_read }, > > 12baa00: 14000008 b 0x12baa20 > 12baa04: d000d501 adrp x1, 0x2d5c000 > 12baa08: 91154021 add x1, x1, #0x550 > 12baa0c: f9400022 ldr x2, [x1] > 12baa10: f9400421 ldr x1, [x1, #8] > 12baa14: 8a010042 and x2, x2, x1 > 12baa18: d3441c42 ubfx x2, x2, #4, #4 > 12baa1c: b4000082 cbz x2, 0x12baa2c > 12baa20: d2a175a0 mov x0, #0xbad0000 // #195887104 > 12baa24: f2994220 movk x0, #0xca11 > 12baa28: d69f03e0 eret > 12baa2c: d2c00080 mov x0, #0x400000000 // #17179869184 > 12baa30: f2b10000 movk x0, #0x8800, lsl #16 > 12baa34: f2800000 movk x0, #0x0 > 12baa38: d51c1100 msr hcr_el2, x0 > 12baa3c: d5033fdf isb > 12baa40: d53c4100 mrs x0, sp_el1 > 12baa44: 9100001f mov sp, x0 > 12baa48: d538d080 mrs x0, tpidr_el1 > 12baa4c: d51cd040 msr tpidr_el2, x0 > 12baa50: d53d1040 mrs x0, cpacr_el12 > 12baa54: d5181040 msr cpacr_el1, x0 > 12baa58: d53dc000 mrs x0, vbar_el12 > 12baa5c: d518c000 msr vbar_el1, x0 > 12baa60: d53c1120 mrs x0, mdcr_el2 > 12baa64: 9272f400 and x0, x0, #0xffffffffffffcfff > 12baa68: 9266f400 and x0, x0, #0xfffffffffcffffff > 12baa6c: d51c1120 msr mdcr_el2, x0 > 12baa70: d53d2040 mrs x0, tcr_el12 > 12baa74: d5182040 msr tcr_el1, x0 > 12baa78: d53d2000 mrs x0, ttbr0_el12 > 12baa7c: d5182000 msr ttbr0_el1, x0 > 12baa80: d53d2020 mrs x0, ttbr1_el12 > 12baa84: d5182020 msr ttbr1_el1, x0 > 12baa88: d53da200 mrs x0, mair_el12 > 12baa8c: d518a200 msr mair_el1, x0 > 12baa90: d5380761 mrs x1, s3_0_c0_c7_3 > 12baa94: d3400c21 ubfx x1, x1, #0, #4 > 12baa98: b4000141 cbz x1, 0x12baac0 > 12baa9c: d53d2060 mrs x0, s3_5_c2_c0_3 OK, this is suspiciously close to the location Ganapatrao was having issues with. Are you running on the same hardware? In any case, we should never take a trap for this access. Can you dump HCR_EL2 at the point where the guest traps (in switch.c)? > >> As for QEMU, it is having issues enabling _EL2 feature although EL2 > >> is supported by checking KVM_CAP_ARM_EL2; need yet to debug this. > > The capability number changes at each release. Make sure you resync > > your includes. > > Been there but it seems a different problem this time. Creating the VM with SVE? NV doesn't support it yet (and it has been the case for a long while). M. -- Without deviation from the norm, progress is not possible.
