All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.