On 2020-07-20 16:40, Andrew Scull wrote:
On Wed, Jul 15, 2020 at 07:44:08PM +0100, Andrew Scull wrote:
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S
b/arch/arm64/kvm/hyp/hyp-entry.S
index e727bee8e110..c441aabb8ab0 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -177,7 +177,6 @@ el2_error:
adr x1, abort_guest_exit_end
ccmp x0, x1, #4, ne
b.ne __hyp_panic
- mov x0, #(1 << ARM_EXIT_WITH_SERROR_BIT)
eret
sb
Having looked at this again, I also meant to remove the hunk below. It
used to check that the SError had actually been taken through the
exception vector but I am removing that.
However, do I need to continue doing that check to make sure the SError
didn't get cancelled (if that is possible) or some other architectural
phenomenon happened that I haven't factored in to my thinking?
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -210,13 +222,8 @@ abort_guest_exit_end:
msr daifset, #4 // Mask aborts
- // If the exception took place, restore the EL1 exception
- // context so that we can report some information.
- // Merge the exception code with the SError pending bit.
- tbz x0, #ARM_EXIT_WITH_SERROR_BIT, 1f
You have now inverted the logic: you detect the SError before
handling it, and set the flag accordingly. Which means that:
- you always enter this function having set ARM_EXIT_WITH_SERROR_BIT
in the error code (which isn't passed to this function).
- you always take an exception, because you *know* there is a pending
SError. Taking the exception on a non-RAS systems consumes it.
- If there is another SError pending after that, something bad happened
at EL2, and we'll explode later on (on return to EL1).
So I think removing this hunk is the right thing to do.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
