Re: [RFC PATCH 00/17] KVM: arm64: Parallelize stage 2 fault handling

2022-04-21 Thread Paolo Bonzini
On 4/21/22 18:30, Ben Gardon wrote: Completely agree. I'm surprised that ARM doesn't have a need for a metadata structure associated with each page of the stage 2 paging structure, but if you don't need it, that definitely makes things simpler. The uses of struct kvm_mmu_page in the TDP MMU

[PATCH] KVM: arm64: Inject exception on out-of-IPA-range translation fault

2022-04-21 Thread Marc Zyngier
When taking an translation fault for an IPA that is outside of the range defined by the hypervisor (between the HW PARange and that exposed to the guest), we stupidly treat it as an IO and forward the access to userspace. Of course, userspace can't do much with it, and things end badly. Arguably,

Re: [PATCH v2 5/5] KVM: arm64: uapi: Add kvm_debug_exit_arch.hsr_high

2022-04-21 Thread Alexandru Elisei
Hi, On Thu, Apr 21, 2022 at 01:58:52PM +0100, Marc Zyngier wrote: > On Thu, 21 Apr 2022 11:05:47 +0100, > Alexandru Elisei wrote: > > > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > > index 93d92130d36c..fd5b6773e3a2 100644 > > --- a/arch/arm64/kvm/handle_exit.c >

Re: [PATCH v2 5/5] KVM: arm64: uapi: Add kvm_debug_exit_arch.hsr_high

2022-04-21 Thread Marc Zyngier
On Thu, 21 Apr 2022 11:05:47 +0100, Alexandru Elisei wrote: > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index 93d92130d36c..fd5b6773e3a2 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c > @@ -121,6 +121,8 @@ static int

[PATCH v2 5/5] KVM: arm64: uapi: Add kvm_debug_exit_arch.hsr_high

2022-04-21 Thread Alexandru Elisei
When userspace is debugging a VM, the kvm_debug_exit_arch part of the kvm_run struct contains arm64 specific debug information: the ESR_EL2 value, encoded in the field "hsr", and the address of the instruction that caused the exception, encoded in the field "far". Linux has moved to treating

[PATCH v2 3/5] arm64: Treat ESR_ELx as a 64-bit register

2022-04-21 Thread Alexandru Elisei
In the initial release of the ARM Architecture Reference Manual for ARMv8-A, the ESR_ELx registers were defined as 32-bit registers. This changed in 2018 with version D.a (ARM DDI 0487D.a) of the architecture, when they became 64-bit registers, with bits [63:32] defined as RES0. In version G.a, a

[PATCH v2 4/5] KVM: arm64: Treat ESR_EL2 as a 64-bit register

2022-04-21 Thread Alexandru Elisei
ESR_EL2 was defined as a 32-bit register in the initial release of the ARM Architecture Manual for Armv8-A, and was later extended to 64 bits, with bits [63:32] RES0. ARMv8.7 introduced FEAT_LS64, which makes use of bits [36:32]. KVM treats ESR_EL1 as a 64-bit register when saving and restoring

[PATCH v2 1/5] arm64: Make ESR_ELx_xVC_IMM_MASK compatible with assembly

2022-04-21 Thread Alexandru Elisei
ESR_ELx_xVC_IMM_MASK is used as a mask for the immediate value for the HVC/SMC instructions. The header file is included by assembly files (like entry.S) and ESR_ELx_xVC_IMM_MASK is not conditioned on __ASSEMBLY__ being undefined. Use the UL() macro for defining the constant's size, as that is

[PATCH v2 2/5] arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall

2022-04-21 Thread Alexandru Elisei
If a compat process tries to execute an unknown system call above the __ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->

[PATCH v2 0/5] arm64: Treat ESR_ELx as a 64-bit register

2022-04-21 Thread Alexandru Elisei
The ESR_EL{1,2} registers were originally 32-bit, then were extended to 64-bit with the upper 32 bits RES0, and in ARM DDI 0487H.a the FEAT_LS64 feature was added which now makes use of the upper bits. This series aims to teach Linux to treat it consistently as a 64-bit register with the goal of

Re: [PATCH v6 7/8] KVM: arm64: Unwind and dump nVHE HYP stacktrace

2022-04-21 Thread Mark Rutland
On Tue, Apr 19, 2022 at 10:37:56AM -0700, Kalesh Singh wrote: > On Wed, Apr 13, 2022 at 6:59 AM Mark Rutland wrote: > > I'm fine with the concept of splitting the unwind and logging steps; this is > > akin to doing: > > > > stack_trace_save_tsk(...); > > ... > >