[PATCH v11 00/43] KVM: arm64: Nested Virtualization support (FEAT_NV2 only)
Ganapatrao Kulkarni
gankulkarni at os.amperecomputing.com
Fri Nov 24 05:22:22 PST 2023
On 24-11-2023 06:21 pm, Marc Zyngier wrote:
> On Fri, 24 Nov 2023 12:34:41 +0000,
> Ganapatrao Kulkarni <gankulkarni at os.amperecomputing.com> wrote:
>>
>>
>>
>> On 24-11-2023 03:49 pm, Marc Zyngier wrote:
>>> On Fri, 24 Nov 2023 09:50:33 +0000,
>>> Ganapatrao Kulkarni <gankulkarni at os.amperecomputing.com> wrote:
>>>>
>>>>
>>>>
>>>> On 23-11-2023 10:14 pm, Marc Zyngier wrote:
>>>>> On Thu, 23 Nov 2023 16:21:48 +0000,
>>>>> Miguel Luis <miguel.luis at oracle.com> 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 at oracle.com> wrote:
>>>>>>>> Hi Marc,
>>>>>>>>
>>>>>>>>> On 20 Nov 2023, at 12:09, Marc Zyngier <maz at kernel.org> 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@kernel.org
>>>>>>>>> [2] https://lore.kernel.org/r/20231120123721.851738-1-maz@kernel.org
>>>>>>>>> [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
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This.
>
>>>>>> 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)?
>>>>>
>>>>
>>>> I have dumped HCR_EL2 before entry to L1 in both V11 and V10.
>>>> on V10 HCR_EL2=0x2743c827c263f
>>>> on V11 HCR_EL2=0x27c3c827c263f
>>>>
>>>> on V11 the function vcpu_el2_e2h_is_set(vcpu) is returning false
>>>> resulting in NV1 bit set along with NV and NV2.
>>>> AFAIK, For L1 to be in VHE, NV1 bit should be zero and NV=NV2=1.
>>>>
>>>> I could boot L1 then L2, if I hack vcpu_el2_e2h_is_set to return true.
>>>> There could be a bug in V11 or E2H0 patchset resulting in
>>>> vcpu_el2_e2h_is_set() returning false?
>>>
>>> The E2H0 series should only force vcpu_el2_e2h_is_set() to return
>>> true, but not set it to false. Can you dump the *guest's* version of
>>> HCR_EL2 at this point?
>>>
>>
>> with V11: vhcr_el2=0x100030080000000 mask=0x100af00ffffffff
>
> How is this value possible if the write to HCR_EL2 has taken place?
> When do you sample this?
I am not sure how and where it got set. I think, whatever it is set, it
is due to false return of vcpu_el2_e2h_is_set(). Need to understand/debug.
The vhcr_el2 value I have shared is traced along with hcr in function
__activate_traps/__compute_hcr.
>
>> with V10: vhcr_el2=0x488000000
>> with hack+V11: vhcr_el2=0x488000000 mask=0x100af00ffffffff
>
> Well, of course, if you constrain the value of HCR_EL2...
>
> M.
>
Thanks,
Ganapat
More information about the linux-arm-kernel
mailing list