From: Ricardo Koller <ricarkol@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 4/5] KVM: selftests: Add exception handling support for aarch64
Date: Fri, 7 May 2021 11:02:56 -0700 [thread overview]
Message-ID: <YJWA0Moczi2kYSjd@google.com> (raw)
In-Reply-To: <877dkapqcj.wl-maz@kernel.org>
On Fri, May 07, 2021 at 03:31:56PM +0100, Marc Zyngier wrote:
> On Mon, 03 May 2021 20:12:21 +0100,
> Ricardo Koller <ricarkol@google.com> wrote:
> >
> > On Mon, May 03, 2021 at 11:32:39AM +0100, Marc Zyngier wrote:
> > > On Sat, 01 May 2021 00:24:06 +0100,
> > > Ricardo Koller <ricarkol@google.com> wrote:
>
> [...]
>
> > > > + .if \vector >= 8
> > > > + mrs x1, sp_el0
> > >
> > > I'm still a bit perplexed by this. SP_EL0 is never changed, since you
> > > always run in handler mode. Therefore, saving/restoring it is only
> > > overhead. If an exception handler wants to introspect it, it is
> > > already available in the relevant system register.
> > >
> > > Or did you have something else in mind for it?
> > >
> >
> > Not really. The reason for saving sp_el0 in there was just for
> > consistency, so that handlers for both el0 and el1 exceptions could
> > get the sp at regs->sp.
>
> We already have sp_el0 consistency by virtue of having it stored in in
> a sysreg.
>
> > Restoring sp_el0 might be too much. So, what do you think of this
> > v3: we keep the saving of sp_el0 into regs->sp (to keep things the
> > same between el0 and el1) and delete the restoring of sp_el0?
>
> To me, the whole purpose of saving some some context is to allow the
> exception handling code to run C code and introspect the interrupted
> state. But saving things that are not affected by the context change
> seems a bit pointless.
>
> One thing I'd like to see though is to save sp_el1 as it was at the
> point of the exception (because that is meaningful to get the
> exception context -- think of an unaligned EL1 stack for example),
> which means correcting the value that gets saved.
Got it. Replacing:
mov x1, sp
with:
add x1, sp, #16 * 17
>
> So I would suggest to *only* save sp_el1, to always save it
> (irrespective of the exception coming from EL0 or EL1), and to save a
> retro-corrected value so that the handler can directly know where the
> previous stack pointer was.
Sounds good, will send a V3 accordingly.
Thanks!
Ricardo
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Ricardo Koller <ricarkol@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
pbonzini@redhat.com, drjones@redhat.com,
alexandru.elisei@arm.com, eric.auger@redhat.com
Subject: Re: [PATCH v2 4/5] KVM: selftests: Add exception handling support for aarch64
Date: Fri, 7 May 2021 11:02:56 -0700 [thread overview]
Message-ID: <YJWA0Moczi2kYSjd@google.com> (raw)
In-Reply-To: <877dkapqcj.wl-maz@kernel.org>
On Fri, May 07, 2021 at 03:31:56PM +0100, Marc Zyngier wrote:
> On Mon, 03 May 2021 20:12:21 +0100,
> Ricardo Koller <ricarkol@google.com> wrote:
> >
> > On Mon, May 03, 2021 at 11:32:39AM +0100, Marc Zyngier wrote:
> > > On Sat, 01 May 2021 00:24:06 +0100,
> > > Ricardo Koller <ricarkol@google.com> wrote:
>
> [...]
>
> > > > + .if \vector >= 8
> > > > + mrs x1, sp_el0
> > >
> > > I'm still a bit perplexed by this. SP_EL0 is never changed, since you
> > > always run in handler mode. Therefore, saving/restoring it is only
> > > overhead. If an exception handler wants to introspect it, it is
> > > already available in the relevant system register.
> > >
> > > Or did you have something else in mind for it?
> > >
> >
> > Not really. The reason for saving sp_el0 in there was just for
> > consistency, so that handlers for both el0 and el1 exceptions could
> > get the sp at regs->sp.
>
> We already have sp_el0 consistency by virtue of having it stored in in
> a sysreg.
>
> > Restoring sp_el0 might be too much. So, what do you think of this
> > v3: we keep the saving of sp_el0 into regs->sp (to keep things the
> > same between el0 and el1) and delete the restoring of sp_el0?
>
> To me, the whole purpose of saving some some context is to allow the
> exception handling code to run C code and introspect the interrupted
> state. But saving things that are not affected by the context change
> seems a bit pointless.
>
> One thing I'd like to see though is to save sp_el1 as it was at the
> point of the exception (because that is meaningful to get the
> exception context -- think of an unaligned EL1 stack for example),
> which means correcting the value that gets saved.
Got it. Replacing:
mov x1, sp
with:
add x1, sp, #16 * 17
>
> So I would suggest to *only* save sp_el1, to always save it
> (irrespective of the exception coming from EL0 or EL1), and to save a
> retro-corrected value so that the handler can directly know where the
> previous stack pointer was.
Sounds good, will send a V3 accordingly.
Thanks!
Ricardo
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2021-05-07 18:03 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 23:24 [PATCH v2 0/5] KVM: selftests: arm64 exception handling and debug test Ricardo Koller
2021-04-30 23:24 ` Ricardo Koller
2021-04-30 23:24 ` [PATCH v2 1/5] KVM: selftests: Rename vm_handle_exception Ricardo Koller
2021-04-30 23:24 ` Ricardo Koller
2021-05-03 11:02 ` Andrew Jones
2021-05-03 11:02 ` Andrew Jones
2021-05-06 12:27 ` Auger Eric
2021-05-06 12:27 ` Auger Eric
2021-04-30 23:24 ` [PATCH v2 2/5] KVM: selftests: Introduce UCALL_UNHANDLED for unhandled vector reporting Ricardo Koller
2021-04-30 23:24 ` Ricardo Koller
2021-05-03 11:09 ` Andrew Jones
2021-05-03 11:09 ` Andrew Jones
2021-05-06 12:27 ` Auger Eric
2021-05-06 12:27 ` Auger Eric
2021-04-30 23:24 ` [PATCH v2 3/5] KVM: selftests: Move GUEST_ASSERT_EQ to utils header Ricardo Koller
2021-04-30 23:24 ` Ricardo Koller
2021-05-03 11:31 ` Andrew Jones
2021-05-03 11:31 ` Andrew Jones
2021-04-30 23:24 ` [PATCH v2 4/5] KVM: selftests: Add exception handling support for aarch64 Ricardo Koller
2021-04-30 23:24 ` Ricardo Koller
2021-05-03 10:32 ` Marc Zyngier
2021-05-03 10:32 ` Marc Zyngier
2021-05-03 19:12 ` Ricardo Koller
2021-05-03 19:12 ` Ricardo Koller
2021-05-06 12:30 ` Auger Eric
2021-05-06 12:30 ` Auger Eric
2021-05-06 19:14 ` Ricardo Koller
2021-05-06 19:14 ` Ricardo Koller
2021-05-07 14:08 ` Auger Eric
2021-05-07 14:08 ` Auger Eric
2021-05-07 17:54 ` Ricardo Koller
2021-05-07 17:54 ` Ricardo Koller
2021-05-12 7:27 ` Ricardo Koller
2021-05-12 7:27 ` Ricardo Koller
2021-05-12 8:19 ` Auger Eric
2021-05-12 8:19 ` Auger Eric
2021-05-12 8:33 ` Marc Zyngier
2021-05-12 8:33 ` Marc Zyngier
2021-05-12 8:52 ` Auger Eric
2021-05-12 8:52 ` Auger Eric
2021-05-12 16:06 ` Ricardo Koller
2021-05-12 16:06 ` Ricardo Koller
2021-05-12 12:59 ` Zenghui Yu
2021-05-12 12:59 ` Zenghui Yu
2021-05-12 13:43 ` Marc Zyngier
2021-05-12 13:43 ` Marc Zyngier
2021-05-12 16:03 ` Ricardo Koller
2021-05-12 16:03 ` Ricardo Koller
2021-05-12 16:18 ` Marc Zyngier
2021-05-12 16:18 ` Marc Zyngier
2021-05-12 21:39 ` Ricardo Koller
2021-05-12 21:39 ` Ricardo Koller
2021-05-07 14:31 ` Marc Zyngier
2021-05-07 14:31 ` Marc Zyngier
2021-05-07 18:02 ` Ricardo Koller [this message]
2021-05-07 18:02 ` Ricardo Koller
2021-05-03 12:39 ` Andrew Jones
2021-05-03 12:39 ` Andrew Jones
2021-04-30 23:24 ` [PATCH v2 5/5] KVM: selftests: Add aarch64/debug-exceptions test Ricardo Koller
2021-04-30 23:24 ` Ricardo Koller
2021-05-03 12:49 ` Andrew Jones
2021-05-03 12:49 ` Andrew Jones
2021-05-24 12:14 ` [PATCH v2 0/5] KVM: selftests: arm64 exception handling and debug test Paolo Bonzini
2021-05-24 12:14 ` Paolo Bonzini
2021-05-24 12:59 ` Marc Zyngier
2021-05-24 12:59 ` Marc Zyngier
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=YJWA0Moczi2kYSjd@google.com \
--to=ricarkol@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=maz@kernel.org \
--cc=pbonzini@redhat.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.