[PATCH v11 00/43] KVM: arm64: Nested Virtualization support (FEAT_NV2 only)
Ganapatrao Kulkarni
gankulkarni at os.amperecomputing.com
Wed Nov 22 03:10:10 PST 2023
On 21-11-2023 03:11 pm, Marc Zyngier wrote:
> On Tue, 21 Nov 2023 09:26:22 +0000,
> Ganapatrao Kulkarni <gankulkarni at os.amperecomputing.com> wrote:
>>
>>
>>
>> On 21-11-2023 02:38 pm, Marc Zyngier wrote:
>>> On Tue, 21 Nov 2023 08:51:35 +0000,
>>> Ganapatrao Kulkarni <gankulkarni at os.amperecomputing.com> wrote:
>>>>
>>>>
>>>> Hi Marc,
>>>>
>>>> On 20-11-2023 06:39 pm, Marc Zyngier 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
>>>>>
>>>>
>>>> V11 series is not booting on Ampere platform (I am yet to debug).
>>>> With lkvm, it is stuck at the very early stage itself and no early
>>>> boot prints/logs.
>>>>
>>>> Are there any changes needed in kvmtool for V11?
>>>
>>> Not really, I'm still using the version I had built for 6.5. Is the
>>> problem with L1 or L2?
>>
>> Stuck in the L1 itself.
>>
>> I am using kvmtool from
>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/kvmtool.git/log/?h=arm64/nv-5.16
>
> Huh. That's positively ancient. Yet, you shouldn't get into a
> situation where the L1 guest locks up.
>
> I have pushed out my kvmtool branch[1]. Please give it a go.
>
No change, still L1 hangs. Captured ftrace and the L1 is keep
looping/faulting around same address across kvm_entry and kvm_exits.
It is a weird behavior, L1 is faulting and looping around MDCR and
AA64MMFR3_EL1 access in function __finalise_el2.
asm:
ffffffc080528a58: d53dc000 mrs x0, vbar_el12
ffffffc080528a5c: d518c000 msr vbar_el1, x0
ffffffc080528a60: d53c1120 mrs x0, mdcr_el2
ffffffc080528a64: 9272f400 and x0, x0, #0xffffffffffffcfff
ffffffc080528a68: 9266f400 and x0, x0, #0xfffffffffcffffff
ffffffc080528a6c: d51c1120 msr mdcr_el2, x0
ffffffc080528a70: d53d2040 mrs x0, tcr_el12
ffffffc080528a74: d5182040 msr tcr_el1, x0
ffffffc080528a78: d53d2000 mrs x0, ttbr0_el12
ffffffc080528a7c: d5182000 msr ttbr0_el1, x0
ffffffc080528a80: d53d2020 mrs x0, ttbr1_el12
ffffffc080528a84: d5182020 msr ttbr1_el1, x0
ffffffc080528a88: d53da200 mrs x0, mair_el12
ffffffc080528a8c: d518a200 msr mair_el1, x0
ffffffc080528a90: d5380761 mrs x1, s3_0_c0_c7_3
ffffffc080528a94: d3400c21 ubfx x1, x1, #0, #4
ffffffc080528a98: b4000141 cbz x1, ffffffc080528ac0
<__finalise_el2+0x270>
ffffffc080528a9c: d53d2060 mrs x0, s3_5_c2_c0_3
ftrace:
kvm-vcpu-0-88776 [001] ...1. 6076.581774: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a6c
kvm-vcpu-0-88776 [001] d..1. 6076.581774: kvm_entry: PC:
0x0000000080528a6c
kvm-vcpu-0-88776 [001] ...1. 6076.581775: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a90
kvm-vcpu-0-88776 [001] d..1. 6076.581776: kvm_entry: PC:
0x0000000080528a90
kvm-vcpu-0-88776 [001] ...1. 6076.581778: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a60
kvm-vcpu-0-88776 [001] d..1. 6076.581778: kvm_entry: PC:
0x0000000080528a60
kvm-vcpu-0-88776 [001] ...1. 6076.581779: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a6c
kvm-vcpu-0-88776 [001] d..1. 6076.581779: kvm_entry: PC:
0x0000000080528a6c
kvm-vcpu-0-88776 [001] ...1. 6076.581780: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a90
kvm-vcpu-0-88776 [001] d..1. 6076.581781: kvm_entry: PC:
0x0000000080528a90
kvm-vcpu-0-88776 [001] ...1. 6076.581783: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a60
kvm-vcpu-0-88776 [001] d..1. 6076.581783: kvm_entry: PC:
0x0000000080528a60
kvm-vcpu-0-88776 [001] ...1. 6076.581784: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a6c
kvm-vcpu-0-88776 [001] d..1. 6076.581784: kvm_entry: PC:
0x0000000080528a6c
kvm-vcpu-0-88776 [001] ...1. 6076.581785: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a90
kvm-vcpu-0-88776 [001] d..1. 6076.581786: kvm_entry: PC:
0x0000000080528a90
kvm-vcpu-0-88776 [001] ...1. 6076.581788: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a60
kvm-vcpu-0-88776 [001] d..1. 6076.581788: kvm_entry: PC:
0x0000000080528a60
kvm-vcpu-0-88776 [001] ...1. 6076.581789: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a6c
kvm-vcpu-0-88776 [001] d..1. 6076.581789: kvm_entry: PC:
0x0000000080528a6c
kvm-vcpu-0-88776 [001] ...1. 6076.581790: kvm_exit: TRAP:
HSR_EC: 0x0018 (SYS64), PC: 0x0000000080528a90
Thanks,
Ganapat
More information about the linux-arm-kernel
mailing list