From: Oliver Upton <hidden> Date: 2021-11-02 09:48:19
KVM does not implement the debug architecture to the letter of the
specification. One such issue is the fact that KVM treats the OS Lock as
RAZ/WI, rather than emulating its behavior on hardware. This series adds
emulation support for the OS Lock to KVM. Emulation is warranted as the
OS Lock affects debug exceptions taken from all ELs, and is not limited
to only the context of the guest.
The 1st patch is a correctness fix for the OSLSR register, ensuring
the trap handler actually is written to suggest WO behavior. Note that
the changed code should never be reached on a correct implementation, as
hardware should generate the undef, not KVM.
The 2nd patch adds the necessary context to track guest values of the
OS Lock bit and exposes the value to userspace for the sake of
migration.
The 3rd patch makes the OSLK bit writable in OSLAR_EL1 (from the guest)
and OSLSR_EL1 (from userspace), but does nothing with its value.
The 4th patch actually implements the OS Lock behavior, disabling all
debug exceptions from the perspective of the guest. This is done by
disabling MDE and SS in MDSCR_EL1. Since software breakpoint
instructions cannot be masked by anything but the OS Lock, we emulate by
trapping debug exceptions to EL2 and skipping the breakpoint. Skip this
whole song and dance altogether if userspace is debugging the guest.
The 5th patch asserts that OSLSR_EL1 is exposed by KVM to userspace
through the KVM_GET_REG_LIST ioctl. Lastly, the 6th patch asserts that
no debug exceptions are routed to the guest when the OSLK bit is set.
This series applies cleanly to 5.15. Tested on an Ampere Altra machine
with the included selftests patches. Additionally, I single-stepped a
guest using kvmtool to make sure userspace debugging is still working
correctly.
[v1]: http://lore.kernel.org/r/20211029003202.158161-1-oupton@google.com
v1 -> v2:
- Added OSLSR_EL1 to get-reg-list test
- Added test cases to debug-exceptions test
- Scrapped the context switching of OSLSR_EL1
- Dropped DFR0 changes, to be addressed in a later series
Oliver Upton (6):
KVM: arm64: Correctly treat writes to OSLSR_EL1 as undefined
KVM: arm64: Stash OSLSR_EL1 in the cpu context
KVM: arm64: Allow guest to set the OSLK bit
KVM: arm64: Emulate the OS Lock
selftests: KVM: Add OSLSR_EL1 to the list of blessed regs
selftests: KVM: Test OS lock behavior
arch/arm64/include/asm/kvm_host.h | 5 ++
arch/arm64/include/asm/sysreg.h | 6 ++
arch/arm64/kvm/debug.c | 20 ++++--
arch/arm64/kvm/handle_exit.c | 8 +++
arch/arm64/kvm/sys_regs.c | 70 ++++++++++++++-----
.../selftests/kvm/aarch64/debug-exceptions.c | 58 ++++++++++++++-
.../selftests/kvm/aarch64/get-reg-list.c | 1 +
7 files changed, 144 insertions(+), 24 deletions(-)
--
2.33.1.1089.g2158813163f-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Oliver Upton <hidden> Date: 2021-11-02 09:48:42
Any valid implementation of the architecture should generate an
undefined exception for writes to a read-only register, such as
OSLSR_EL1. Nonetheless, the KVM handler actually implements write-ignore
behavior.
Align the trap handler for OSLSR_EL1 with hardware behavior. If such a
write ever traps to EL2, inject an undef into the guest and print a
warning.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/kvm/sys_regs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
Any valid implementation of the architecture should generate an
undefined exception for writes to a read-only register, such as
OSLSR_EL1. Nonetheless, the KVM handler actually implements write-ignore
behavior.
Align the trap handler for OSLSR_EL1 with hardware behavior. If such a
write ever traps to EL2, inject an undef into the guest and print a
warning.
Signed-off-by: Oliver Upton <redacted>
From: Oliver Upton <hidden> Date: 2021-11-02 09:48:46
An upcoming change to KVM will context switch the OS Lock status between
guest/host. Add OSLSR_EL1 to the cpu context and handle guest reads
using the stored value.
Wire up a custom handler for writes from userspace and prevent any of
the invariant bits from changing.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/sys_regs.c | 31 ++++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
From: Oliver Upton <hidden> Date: 2021-11-02 09:53:39
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted hunk
An upcoming change to KVM will context switch the OS Lock status between
guest/host. Add OSLSR_EL1 to the cpu context and handle guest reads
using the stored value.
Wire up a custom handler for writes from userspace and prevent any of
the invariant bits from changing.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/sys_regs.c | 31 ++++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
@@ -172,6 +172,7 @@ enum vcpu_sysreg {MDSCR_EL1,/* Monitor Debug System Control Register */MDCCINT_EL1,/* Monitor Debug Comms Channel Interrupt Enable Reg */DISR_EL1,/* Deferred Interrupt Status Register */+OSLSR_EL1,/* OS Lock Status Register */
Sorry Marc, forgot to move this up per your suggestion on the last
series. Only caught it once the patch went out the door.
--
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Nov 2, 2021 at 2:51 AM Oliver Upton [off-list ref] wrote:
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted
An upcoming change to KVM will context switch the OS Lock status between
guest/host. Add OSLSR_EL1 to the cpu context and handle guest reads
using the stored value.
Wire up a custom handler for writes from userspace and prevent any of
the invariant bits from changing.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/sys_regs.c | 31 ++++++++++++++++++++++++-------
2 files changed, 25 insertions(+), 7 deletions(-)
From: Oliver Upton <hidden> Date: 2021-11-02 09:49:24
Allow writes to OSLAR and forward the OSLK bit to OSLSR. Change the
reset value of the OSLK bit to 1. Allow the value to be migrated by
making OSLSR_EL1.OSLK writable from userspace.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/sysreg.h | 6 ++++++
arch/arm64/kvm/sys_regs.c | 35 +++++++++++++++++++++++++--------
2 files changed, 33 insertions(+), 8 deletions(-)
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted hunk
Allow writes to OSLAR and forward the OSLK bit to OSLSR. Change the
reset value of the OSLK bit to 1. Allow the value to be migrated by
making OSLSR_EL1.OSLK writable from userspace.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/sysreg.h | 6 ++++++
arch/arm64/kvm/sys_regs.c | 35 +++++++++++++++++++++++++--------
2 files changed, 33 insertions(+), 8 deletions(-)
Reviewed-by: Reiji Watanabe <redacted>
I assume the reason why you changed the reset value for the
register is because Arm ARM says "the On a Cold reset,
this field resets to 1".
"4.82 KVM_ARM_VCPU_INIT" in Documentation/virt/kvm/api.rst says:
-------------------------------------------------------------
- System registers: Reset to their architecturally defined
values as for a warm reset to EL1 (resp. SVC)
-------------------------------------------------------------
Since Arm ARM doesn't say anything about a warm reset for the field,
I would guess the bit doesn't necessarily need to be set.
Thanks,
Reiji
On Wed, Nov 03, 2021 at 08:31:35PM -0700, Reiji Watanabe wrote:
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted
Allow writes to OSLAR and forward the OSLK bit to OSLSR. Change the
reset value of the OSLK bit to 1. Allow the value to be migrated by
making OSLSR_EL1.OSLK writable from userspace.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/sysreg.h | 6 ++++++
arch/arm64/kvm/sys_regs.c | 35 +++++++++++++++++++++++++--------
2 files changed, 33 insertions(+), 8 deletions(-)
Reviewed-by: Reiji Watanabe <redacted>
I assume the reason why you changed the reset value for the
register is because Arm ARM says "the On a Cold reset,
this field resets to 1".
"4.82 KVM_ARM_VCPU_INIT" in Documentation/virt/kvm/api.rst says:
-------------------------------------------------------------
- System registers: Reset to their architecturally defined
values as for a warm reset to EL1 (resp. SVC)
-------------------------------------------------------------
Since Arm ARM doesn't say anything about a warm reset for the field,
I would guess the bit doesn't necessarily need to be set.
That would be great, because it would avoid the migration issue that
Oliver described in [PATCH v2 4/6]:
There is an issue, though, with migration: older KVM will not show
OSLSR_EL1 on KVM_GET_REG_LIST. However, in order to provide an
architectural OS Lock, its reset value must be 1 (enabled). This would
all have the effect of discarding the guest's OS lock value and
blocking all debug exceptions intended for the guest until the next
reboot.
From: Oliver Upton <hidden> Date: 2021-11-04 04:41:58
On Wed, Nov 03, 2021 at 08:47:42PM -0700, Ricardo Koller wrote:
On Wed, Nov 03, 2021 at 08:31:35PM -0700, Reiji Watanabe wrote:
quoted
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted
Allow writes to OSLAR and forward the OSLK bit to OSLSR. Change the
reset value of the OSLK bit to 1. Allow the value to be migrated by
making OSLSR_EL1.OSLK writable from userspace.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/sysreg.h | 6 ++++++
arch/arm64/kvm/sys_regs.c | 35 +++++++++++++++++++++++++--------
2 files changed, 33 insertions(+), 8 deletions(-)
Reviewed-by: Reiji Watanabe <redacted>
I assume the reason why you changed the reset value for the
register is because Arm ARM says "the On a Cold reset,
this field resets to 1".
"4.82 KVM_ARM_VCPU_INIT" in Documentation/virt/kvm/api.rst says:
-------------------------------------------------------------
- System registers: Reset to their architecturally defined
values as for a warm reset to EL1 (resp. SVC)
-------------------------------------------------------------
Since Arm ARM doesn't say anything about a warm reset for the field,
I would guess the bit doesn't necessarily need to be set.
That would be great, because it would avoid the migration issue that
Oliver described in [PATCH v2 4/6]:
Yeah, awesome! Means I can be even lazier and things will "Just Work"
:-)
--
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Oliver Upton <hidden> Date: 2021-11-02 09:49:35
The OS lock blocks all debug exceptions at every EL. To date, KVM has
not implemented the OS lock for its guests, despite the fact that it is
mandatory per the architecture. Simple context switching between the
guest and host is not appropriate, as its effects are not constrained to
the guest context.
Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby
blocking all but software breakpoint instructions. To handle breakpoint
instructions, trap debug exceptions to EL2 and skip the instruction.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 4 ++++
arch/arm64/kvm/debug.c | 20 +++++++++++++++-----
arch/arm64/kvm/handle_exit.c | 8 ++++++++
arch/arm64/kvm/sys_regs.c | 6 +++---
4 files changed, 30 insertions(+), 8 deletions(-)
@@ -95,8 +95,11 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)MDCR_EL2_TDRA|MDCR_EL2_TDOSA);-/* Is the VM being debugged by userspace? */-if(vcpu->guest_debug)+/*+*CheckiftheVMisbeingdebuggedbyuserspaceortheguesthas+*enabledtheOSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu))/* Route all software debug exceptions to EL2 */vcpu->arch.mdcr_el2|=MDCR_EL2_TDE;
@@ -160,8 +163,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)kvm_arm_setup_mdcr_el2(vcpu);-/* Is Guest debugging in effect? */-if(vcpu->guest_debug){+/*+*Checkiftheguestisbeingdebuggedoriftheguesthasenabledthe+*OSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu)){/* Save guest debug state */save_guest_debug_regs(vcpu);
On Tue, Nov 02, 2021 at 09:46:49AM +0000, Oliver Upton wrote:
quoted hunk
The OS lock blocks all debug exceptions at every EL. To date, KVM has
not implemented the OS lock for its guests, despite the fact that it is
mandatory per the architecture. Simple context switching between the
guest and host is not appropriate, as its effects are not constrained to
the guest context.
Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby
blocking all but software breakpoint instructions. To handle breakpoint
instructions, trap debug exceptions to EL2 and skip the instruction.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 4 ++++
arch/arm64/kvm/debug.c | 20 +++++++++++++++-----
arch/arm64/kvm/handle_exit.c | 8 ++++++++
arch/arm64/kvm/sys_regs.c | 6 +++---
4 files changed, 30 insertions(+), 8 deletions(-)
@@ -95,8 +95,11 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)MDCR_EL2_TDRA|MDCR_EL2_TDOSA);-/* Is the VM being debugged by userspace? */-if(vcpu->guest_debug)+/*+*CheckiftheVMisbeingdebuggedbyuserspaceortheguesthas+*enabledtheOSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu))/* Route all software debug exceptions to EL2 */vcpu->arch.mdcr_el2|=MDCR_EL2_TDE;
@@ -160,8 +163,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)kvm_arm_setup_mdcr_el2(vcpu);-/* Is Guest debugging in effect? */-if(vcpu->guest_debug){+/*+*Checkiftheguestisbeingdebuggedoriftheguesthasenabledthe+*OSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu)){/* Save guest debug state */save_guest_debug_regs(vcpu);
I think this is missing the case where the guest is being debugged by
userspace _and_ from inside (the guest) at the same time. In this
situation, the vmm gets a KVM_EXIT_DEBUG and if it doesn't know what to
do with it, it injects the exception into the guest (1). With this "else
if", the guest would still get the debug exception when the os lock is
enabled.
(1) kvm_arm_handle_debug() is the one doing this in QEMU source code.
quoted hunk
}
}
@@ -244,7 +254,7 @@ void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) { trace_kvm_arm_clear_debug(vcpu->guest_debug);- if (vcpu->guest_debug) {+ if (vcpu->guest_debug || kvm_vcpu_os_lock_enabled(vcpu)) { restore_guest_debug_regs(vcpu); /*
From: Oliver Upton <hidden> Date: 2021-11-03 00:36:51
Hi Ricardo,
On Tue, Nov 2, 2021 at 4:45 PM Ricardo Koller [off-list ref] wrote:
On Tue, Nov 02, 2021 at 09:46:49AM +0000, Oliver Upton wrote:
quoted
The OS lock blocks all debug exceptions at every EL. To date, KVM has
not implemented the OS lock for its guests, despite the fact that it is
mandatory per the architecture. Simple context switching between the
guest and host is not appropriate, as its effects are not constrained to
the guest context.
Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby
blocking all but software breakpoint instructions. To handle breakpoint
instructions, trap debug exceptions to EL2 and skip the instruction.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 4 ++++
arch/arm64/kvm/debug.c | 20 +++++++++++++++-----
arch/arm64/kvm/handle_exit.c | 8 ++++++++
arch/arm64/kvm/sys_regs.c | 6 +++---
4 files changed, 30 insertions(+), 8 deletions(-)
@@ -95,8 +95,11 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)MDCR_EL2_TDRA|MDCR_EL2_TDOSA);-/* Is the VM being debugged by userspace? */-if(vcpu->guest_debug)+/*+*CheckiftheVMisbeingdebuggedbyuserspaceortheguesthas+*enabledtheOSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu))/* Route all software debug exceptions to EL2 */vcpu->arch.mdcr_el2|=MDCR_EL2_TDE;
@@ -160,8 +163,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)kvm_arm_setup_mdcr_el2(vcpu);-/* Is Guest debugging in effect? */-if(vcpu->guest_debug){+/*+*Checkiftheguestisbeingdebuggedoriftheguesthasenabledthe+*OSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu)){/* Save guest debug state */save_guest_debug_regs(vcpu);
I think this is missing the case where the guest is being debugged by
userspace _and_ from inside (the guest) at the same time. In this
situation, the vmm gets a KVM_EXIT_DEBUG and if it doesn't know what to
do with it, it injects the exception into the guest (1). With this "else
if", the guest would still get the debug exception when the os lock is
enabled.
(1) kvm_arm_handle_debug() is the one doing this in QEMU source code.
I wonder if this is a problem that KVM should even handle. KVM doesn't
do anything to help userspace inject the debug exception into the
guest, and from reading kvm_arm_handle_debug() it would seem that QEMU
is manually injecting the exception to EL1 and setting the PC to the
appropriate vector.
There is an issue, though, with migration: older KVM will not show
OSLSR_EL1 on KVM_GET_REG_LIST. However, in order to provide an
architectural OS Lock, its reset value must be 1 (enabled). This would
all have the effect of discarding the guest's OS lock value and
blocking all debug exceptions intended for the guest until the next
reboot.
So it would seem that userspace needs to know about the OSLK bit to
correctly inject debug exceptions and migrate guests. If opt-in is
heavyweight, we could cure the migration issue by explicitly
documenting the OS lock being disabled out of reset as an erratum of
KVM. Doing so would be consistent with all prior versions of KVM. Of
course, adopting nonarchitected behavior in perpetuity seems a bit
unsavory :-)
--
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Oliver,
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted hunk
The OS lock blocks all debug exceptions at every EL. To date, KVM has
not implemented the OS lock for its guests, despite the fact that it is
mandatory per the architecture. Simple context switching between the
guest and host is not appropriate, as its effects are not constrained to
the guest context.
Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby
blocking all but software breakpoint instructions. To handle breakpoint
instructions, trap debug exceptions to EL2 and skip the instruction.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 4 ++++
arch/arm64/kvm/debug.c | 20 +++++++++++++++-----
arch/arm64/kvm/handle_exit.c | 8 ++++++++
arch/arm64/kvm/sys_regs.c | 6 +++---
4 files changed, 30 insertions(+), 8 deletions(-)
@@ -95,8 +95,11 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)MDCR_EL2_TDRA|MDCR_EL2_TDOSA);-/* Is the VM being debugged by userspace? */-if(vcpu->guest_debug)+/*+*CheckiftheVMisbeingdebuggedbyuserspaceortheguesthas+*enabledtheOSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu))
IMHO, it might be nicer to create a macro or function that abstracts the
condition that needs save_guest_debug_regs/restore_guest_debug_regs.
(rather than putting those conditions in each part of codes where they
are needed)
Thanks,
Reiji
quoted hunk
/* Route all software debug exceptions to EL2 */
vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
@@ -160,8 +163,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) kvm_arm_setup_mdcr_el2(vcpu);- /* Is Guest debugging in effect? */- if (vcpu->guest_debug) {+ /*+ * Check if the guest is being debugged or if the guest has enabled the+ * OS lock.+ */+ if (vcpu->guest_debug || kvm_vcpu_os_lock_enabled(vcpu)) { /* Save guest debug state */ save_guest_debug_regs(vcpu);
From: Oliver Upton <hidden> Date: 2021-11-05 05:38:32
On Thu, Nov 4, 2021 at 8:56 PM Reiji Watanabe [off-list ref] wrote:
Hi Oliver,
On Tue, Nov 2, 2021 at 2:47 AM Oliver Upton [off-list ref] wrote:
quoted
The OS lock blocks all debug exceptions at every EL. To date, KVM has
not implemented the OS lock for its guests, despite the fact that it is
mandatory per the architecture. Simple context switching between the
guest and host is not appropriate, as its effects are not constrained to
the guest context.
Emulate the OS Lock by clearing MDE and SS in MDSCR_EL1, thereby
blocking all but software breakpoint instructions. To handle breakpoint
instructions, trap debug exceptions to EL2 and skip the instruction.
Signed-off-by: Oliver Upton <redacted>
---
arch/arm64/include/asm/kvm_host.h | 4 ++++
arch/arm64/kvm/debug.c | 20 +++++++++++++++-----
arch/arm64/kvm/handle_exit.c | 8 ++++++++
arch/arm64/kvm/sys_regs.c | 6 +++---
4 files changed, 30 insertions(+), 8 deletions(-)
I would think the name of this macro might sound like it generates
a code that is evaluated as bool :)
Hey! Nobody ever said this would coerce the returned value into a bool :-P
In all seriousness, good point. I agree that the statement should
obviously evaluate to a bool, given the naming of the macro.
quoted
+
int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
struct kvm_device_attr *attr);
int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
@@ -95,8 +95,11 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)MDCR_EL2_TDRA|MDCR_EL2_TDOSA);-/* Is the VM being debugged by userspace? */-if(vcpu->guest_debug)+/*+*CheckiftheVMisbeingdebuggedbyuserspaceortheguesthas+*enabledtheOSlock.+*/+if(vcpu->guest_debug||kvm_vcpu_os_lock_enabled(vcpu))
IMHO, it might be nicer to create a macro or function that abstracts the
condition that needs save_guest_debug_regs/restore_guest_debug_regs.
(rather than putting those conditions in each part of codes where they
are needed)
I completely agree, and it comes with the added benefit that the
macro/function can be named something informative so as to suggest the
purpose for saving guest registers.
Thanks for the review!
--
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Oliver Upton <hidden> Date: 2021-11-02 09:49:51
OSLSR_EL1 is now part of the visible system register state. Add it to
the get-reg-list selftest to ensure we keep it that way.
Signed-off-by: Oliver Upton <redacted>
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 1 +
1 file changed, 1 insertion(+)
From: Oliver Upton <hidden> Date: 2021-11-02 09:50:28
KVM now correctly handles the OS Lock for its guests. When set, KVM
blocks all debug exceptions originating from the guest. Add test cases
to the debug-exceptions test to assert that software breakpoint,
hardware breakpoint, watchpoint, and single-step exceptions are in fact
blocked.
Signed-off-by: Oliver Upton <redacted>
---
.../selftests/kvm/aarch64/debug-exceptions.c | 58 ++++++++++++++++++-
1 file changed, 56 insertions(+), 2 deletions(-)
From: Marc Zyngier <maz@kernel.org> Date: 2021-11-02 11:11:24
Hi Oliver,
On Tue, 02 Nov 2021 09:46:51 +0000,
Oliver Upton [off-list ref] wrote:
quoted hunk
KVM now correctly handles the OS Lock for its guests. When set, KVM
blocks all debug exceptions originating from the guest. Add test cases
to the debug-exceptions test to assert that software breakpoint,
hardware breakpoint, watchpoint, and single-step exceptions are in fact
blocked.
Signed-off-by: Oliver Upton <redacted>
---
.../selftests/kvm/aarch64/debug-exceptions.c | 58 ++++++++++++++++++-
1 file changed, 56 insertions(+), 2 deletions(-)
I haven't had a change to properly review the series, but this one
definitely caught my eye. My expectations are that BRK is *not*
affected by the OS Lock. The ARMv8 ARM goes as far as saying:
<quote>
Breakpoint Instruction exceptions are enabled regardless of the state
of the OS Lock and the OS Double Lock.
</quote>
as well as:
<quote>
There is no enable control for Breakpoint Instruction exceptions. They
are always enabled, and cannot be masked.
</quote>
I wonder how your test succeeds, though.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Oliver Upton <hidden> Date: 2021-11-02 14:55:36
Hey Marc,
On Tue, Nov 2, 2021 at 4:09 AM Marc Zyngier [off-list ref] wrote:
Hi Oliver,
On Tue, 02 Nov 2021 09:46:51 +0000,
Oliver Upton [off-list ref] wrote:
quoted
KVM now correctly handles the OS Lock for its guests. When set, KVM
blocks all debug exceptions originating from the guest. Add test cases
to the debug-exceptions test to assert that software breakpoint,
hardware breakpoint, watchpoint, and single-step exceptions are in fact
blocked.
Signed-off-by: Oliver Upton <redacted>
---
.../selftests/kvm/aarch64/debug-exceptions.c | 58 ++++++++++++++++++-
1 file changed, 56 insertions(+), 2 deletions(-)
I haven't had a change to properly review the series, but this one
definitely caught my eye. My expectations are that BRK is *not*
affected by the OS Lock. The ARMv8 ARM goes as far as saying:
<quote>
Breakpoint Instruction exceptions are enabled regardless of the state
of the OS Lock and the OS Double Lock.
</quote>
as well as:
<quote>
There is no enable control for Breakpoint Instruction exceptions. They
are always enabled, and cannot be masked.
</quote>
/facepalm I had thought I read "Breakpoint Instruction exceptions" in
the list on D2.5 "The effect of powerdown on debug exceptions",
although on second read I most definitely did not. And if I had read
the bottom of the section, I'd of seen one of the quotes.
I wonder how your test succeeds, though.
Probably because the expectations I wrote match the non-architected
behavior I implemented :-)
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Oliver Upton <hidden> Date: 2021-11-02 20:03:49
On Tue, Nov 2, 2021 at 7:53 AM Oliver Upton [off-list ref] wrote:
quoted
I haven't had a change to properly review the series, but this one
definitely caught my eye. My expectations are that BRK is *not*
affected by the OS Lock. The ARMv8 ARM goes as far as saying:
<quote>
Breakpoint Instruction exceptions are enabled regardless of the state
of the OS Lock and the OS Double Lock.
</quote>
as well as:
<quote>
There is no enable control for Breakpoint Instruction exceptions. They
are always enabled, and cannot be masked.
</quote>
/facepalm I had thought I read "Breakpoint Instruction exceptions" in
the list on D2.5 "The effect of powerdown on debug exceptions",
although on second read I most definitely did not. And if I had read
the bottom of the section, I'd of seen one of the quotes.
quoted
I wonder how your test succeeds, though.
Probably because the expectations I wrote match the non-architected
behavior I implemented :-)
Alright, gave the series a good once over after this and fixed up
quite a few things. Unless you're ready for it, I'll hold back for a
bit to avoid spamming inboxes. As an FYI, here's the fixes I have
queued up:
v2 -> v3:
- Stop trapping debug exceptions when the OS Lock is enabled, as it
does *not* block software breakpoint exceptions (Marc)
- Trap accesses to debug registers if the OS Lock is enabled to prevent
the guest from wiping out KVM's configuration of MDSCR_EL1
- Update the debug-exceptions test to expect a software breakpoint
exception even when the OS Lock is enabled.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Nov 02, 2021 at 09:46:51AM +0000, Oliver Upton wrote:
quoted hunk
KVM now correctly handles the OS Lock for its guests. When set, KVM
blocks all debug exceptions originating from the guest. Add test cases
to the debug-exceptions test to assert that software breakpoint,
hardware breakpoint, watchpoint, and single-step exceptions are in fact
blocked.
Signed-off-by: Oliver Upton <redacted>
---
.../selftests/kvm/aarch64/debug-exceptions.c | 58 ++++++++++++++++++-
1 file changed, 56 insertions(+), 2 deletions(-)
Yep, I'll do this once I rebase onto 5.16, as the sysreg rework isn't
available til then.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel