From mboxrd@z Thu Jan 1 00:00:00 1970 From: alex.bennee@linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=) Date: Thu, 08 Nov 2018 12:26:16 +0000 Subject: [RFC PATCH] KVM: arm64: don't single-step for non-emulated faults In-Reply-To: References: <20181107171031.22573-1-alex.bennee@linaro.org> Message-ID: <87sh0b69hz.fsf@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Peter Maydell writes: > On 7 November 2018 at 17:39, Peter Maydell wrote: >> On 7 November 2018 at 17:10, Alex Benn?e wrote: >>> Not all faults handled by handle_exit are instruction emulations. For >>> example a ESR_ELx_EC_IABT will result in the page tables being updated >>> but the instruction that triggered the fault hasn't actually executed >>> yet. We use the simple heuristic of checking for a changed PC before >>> seeing if kvm_arm_handle_step_debug wants to claim we stepped an >>> instruction. >>> >>> Signed-off-by: Alex Benn?e >> >> What's the rationale for this change? Presumably it's fixing >> something, but the commit message doesn't really say what... >> >> This feels to me like it's working around the fact that >> we've separated two things ("advance pc (or set it if we're >> going to make the guest take an exception)" and "notice that >> we have completed a single step") that should be handled >> at one point in the code. > > ...so for instance if your guest PC is at the entrypoint for > an exception, and you singlestep and take the same exception > again, this should count as a single step completed, even > though the PC has not changed. Granted, that's a little > contrived, but it can happen in cases where the guest gets > completely confused and is sitting in a tight loop taking > exceptions because there's no ram at the vector table > address, or whatever. The alternative I thought of as I was hacking^H^H^H^H^H^H carefully engineering this was to expand arm_exit_handlers[] and tag each handler that was an instruction emulation and gate on that. -- Alex Benn?e