From: Mark Rutland <mark.rutland@arm.com> To: Peter Maydell <peter.maydell@linaro.org> Cc: "Alex Bennée" <alex.bennee@linaro.org>, kvm-devel <kvm@vger.kernel.org>, "Marc Zyngier" <marc.zyngier@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>, "Will Deacon" <will.deacon@arm.com>, "open list" <linux-kernel@vger.kernel.org>, "Christoffer Dall" <christoffer.dall@linaro.org>, kvmarm@lists.cs.columbia.edu, arm-mail-list <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC PATCH] KVM: arm64: don't single-step for non-emulated faults Date: Fri, 9 Nov 2018 13:29:56 +0000 [thread overview] Message-ID: <20181109132955.kqfccmqrugfj5rkl@lakrids.cambridge.arm.com> (raw) In-Reply-To: <CAFEAcA-xuUPukf9EPeetr_+RSU7FPDMXmyk3zbjY=FcV65CF=g@mail.gmail.com> On Fri, Nov 09, 2018 at 12:56:54PM +0000, Peter Maydell wrote: > On 9 November 2018 at 12:49, Mark Rutland <mark.rutland@arm.com> wrote: > > I'm not saying anything about *decisions*. I'm saying that we can make > > the state consistent by advancing the singlestep state in the same way > > that HW does, at the instant it advances the PC. > > > > i.e. do that in kvm_skip_instr(), as I've done in my local tree. > > > > That mirrors the HW, and we don't need to special-case any handling for > > emulated vs non-emulated instructions. > > You also need to do it in the "set PC because we're making the guest > take an exception" code path, which doesn't go through kvm_skip_instr(). Sure. > This corresponds to the two kinds of "step completed" in hardware as > noted in DDI0487D.a D2.12.3 fig D2-3 footnote b: > * executing the instruction to be stepped without taking an exception > * taking an exception to an exception level that debug exceptions > are enabled from [ie guest EL1 in our case] Thanks for the pointer! Mark.
WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH] KVM: arm64: don't single-step for non-emulated faults Date: Fri, 9 Nov 2018 13:29:56 +0000 [thread overview] Message-ID: <20181109132955.kqfccmqrugfj5rkl@lakrids.cambridge.arm.com> (raw) In-Reply-To: <CAFEAcA-xuUPukf9EPeetr_+RSU7FPDMXmyk3zbjY=FcV65CF=g@mail.gmail.com> On Fri, Nov 09, 2018 at 12:56:54PM +0000, Peter Maydell wrote: > On 9 November 2018 at 12:49, Mark Rutland <mark.rutland@arm.com> wrote: > > I'm not saying anything about *decisions*. I'm saying that we can make > > the state consistent by advancing the singlestep state in the same way > > that HW does, at the instant it advances the PC. > > > > i.e. do that in kvm_skip_instr(), as I've done in my local tree. > > > > That mirrors the HW, and we don't need to special-case any handling for > > emulated vs non-emulated instructions. > > You also need to do it in the "set PC because we're making the guest > take an exception" code path, which doesn't go through kvm_skip_instr(). Sure. > This corresponds to the two kinds of "step completed" in hardware as > noted in DDI0487D.a D2.12.3 fig D2-3 footnote b: > * executing the instruction to be stepped without taking an exception > * taking an exception to an exception level that debug exceptions > are enabled from [ie guest EL1 in our case] Thanks for the pointer! Mark.
next prev parent reply other threads:[~2018-11-09 13:30 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-07 17:10 [RFC PATCH] KVM: arm64: don't single-step for non-emulated faults Alex Bennée 2018-11-07 17:10 ` Alex Bennée 2018-11-07 17:10 ` Alex Bennée 2018-11-07 17:39 ` Peter Maydell 2018-11-07 17:39 ` Peter Maydell 2018-11-07 17:53 ` Peter Maydell 2018-11-07 17:53 ` Peter Maydell 2018-11-08 12:26 ` Alex Bennée 2018-11-08 12:26 ` Alex Bennée 2018-11-07 18:01 ` Mark Rutland 2018-11-07 18:01 ` Mark Rutland 2018-11-07 18:08 ` Mark Rutland 2018-11-07 18:08 ` Mark Rutland 2018-11-07 18:08 ` Mark Rutland 2018-11-08 12:40 ` Alex Bennée 2018-11-08 12:40 ` Alex Bennée 2018-11-08 13:51 ` Mark Rutland 2018-11-08 13:51 ` Mark Rutland 2018-11-08 14:28 ` Alex Bennée 2018-11-08 14:28 ` Alex Bennée 2018-11-08 14:38 ` Peter Maydell 2018-11-08 14:38 ` Peter Maydell 2018-11-09 11:56 ` Mark Rutland 2018-11-09 11:56 ` Mark Rutland 2018-11-09 12:24 ` Alex Bennée 2018-11-09 12:24 ` Alex Bennée 2018-11-09 12:49 ` Mark Rutland 2018-11-09 12:49 ` Mark Rutland 2018-11-09 12:56 ` Peter Maydell 2018-11-09 12:56 ` Peter Maydell 2018-11-09 13:29 ` Mark Rutland [this message] 2018-11-09 13:29 ` Mark Rutland
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181109132955.kqfccmqrugfj5rkl@lakrids.cambridge.arm.com \ --to=mark.rutland@arm.com \ --cc=alex.bennee@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=christoffer.dall@linaro.org \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=peter.maydell@linaro.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.