From: Riku Voipio <riku.voipio@iki.fi>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Eduardo Habkost <ehabkost@redhat.com>,
Sergey Fedorov <sergey.fedorov@linaro.org>,
Patch Tracking <patches@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] user-exec: cpu_resume_from_signal() cleanups
Date: Tue, 7 Jun 2016 10:59:30 +0300 [thread overview]
Message-ID: <20160607075930.GA19978@beaming.home> (raw)
In-Reply-To: <CAFEAcA9wJWJ+ApFO_3o_cOWG+tA-U4zE5tYSPbkRCWf40tAD0g@mail.gmail.com>
On Mon, Jun 06, 2016 at 05:57:35PM +0100, Peter Maydell wrote:
> On 6 June 2016 at 15:55, Peter Maydell <peter.maydell@linaro.org> wrote:
> > Ping!
>
> Thanks for the review, Sergey. Unless anybody else wants to review
> or wants to take it through their tree (Riku?), I propose to apply
> this to master sometime later this week.
Feel free to apply these yourself,
Acked-by: Riku Voipio <riku.voipio@linaro.org>
> thanks
> -- PMM
>
> > On 17 May 2016 at 15:18, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> I was trying to reason about user-mode's handling of signal masks,
> >> and I found our current code a bit confusing, so I cleaned it up.
> >>
> >> At the moment for user-only mode cpu_resume_from_signal() takes a
> >> usercontext pointer; if this is non-NULL then it has some awkward
> >> OS and CPU specific code to set the signal mask from something
> >> inside the usercontext before doing the same kind of siglongjmp()
> >> that the softmmu cpu_resume_from_signal() does.
> >>
> >> In fact the two use cases are completely separate:
> >> * almost all calls to cpu_resume_from_signal() pass a NULL puc
> >> argument (and most of those are softmmu-only anyway)
> >> * only the code path handle_cpu_signal -> page_unprotect ->
> >> tb_invalidate_phys_page -> cpu_resume_from_signal will pass
> >> a non-NULL puc.
> >>
> >> The cleanups are:
> >> * pull the call to cpu_resume_from_signal() up through the
> >> callstack so we do the signal mask manipulation in
> >> handle_cpu_signal()
> >> * drop the OS/CPU spceific code to get a signal mask out of
> >> a usercontext, because in the specific case of handle_cpu_signal()
> >> we already have the signal mask value and can just use it
> >> * rename cpu_resume_from_signal() to cpu_loop_exit_noexc(),
> >> since all the remaining callsites are not in fact signal handlers
> >> or even called from signal handlers
> >> * get rid of an ugly TARGET_I386 ifdef in user-exec.c by moving
> >> the i386-specific code into its handle_mmu_fault hook.
> >>
> >> Changes v1->v2:
> >> * patches 1-4 are the same and already reviewed
> >> * patch 5 is new, and just adds a clarifying comment to
> >> do_interrupt_user()
> >> * patch 6 is the old patch 5, and now sets env->exception_next_eip
> >> to -1 as a clear indication that the value is not going to be used
> >> (as noted in the comment in the new patch 5)
> >>
> >> thanks
> >> -- PMM
> >>
> >>
> >> Peter Maydell (6):
> >> translate-all.c: Don't pass puc, locked to tb_invalidate_phys_page()
> >> user-exec: Push resume-from-signal code out to handle_cpu_signal()
> >> cpu-exec: Rename cpu_resume_from_signal() to cpu_loop_exit_noexc()
> >> user-exec: Don't reextract sigmask from usercontext pointer
> >> target-i386: Add comment about do_interrupt_user() next_eip argument
> >> target-i386: Move user-mode exception actions out of user-exec.c
> >>
> >> cpu-exec-common.c | 8 ++---
> >> exec.c | 2 +-
> >> hw/i386/kvmvapic.c | 2 +-
> >> include/exec/exec-all.h | 2 +-
> >> target-i386/bpt_helper.c | 2 +-
> >> target-i386/helper.c | 2 ++
> >> target-i386/seg_helper.c | 6 +++-
> >> target-lm32/helper.c | 2 +-
> >> target-s390x/helper.c | 2 +-
> >> target-xtensa/helper.c | 2 +-
> >> translate-all.c | 40 ++++++++++++---------
> >> translate-all.h | 2 +-
> >> user-exec.c | 93 +++++++++++++++++++++---------------------------
> >> 13 files changed, 82 insertions(+), 83 deletions(-)
> >>
> >> --
> >> 1.9.1
next prev parent reply other threads:[~2016-06-07 7:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 14:18 [Qemu-devel] [PATCH v2 0/6] user-exec: cpu_resume_from_signal() cleanups Peter Maydell
2016-05-17 14:18 ` [Qemu-devel] [PATCH v2 1/6] translate-all.c: Don't pass puc, locked to tb_invalidate_phys_page() Peter Maydell
2016-05-17 14:18 ` [Qemu-devel] [PATCH v2 2/6] user-exec: Push resume-from-signal code out to handle_cpu_signal() Peter Maydell
2016-05-17 14:18 ` [Qemu-devel] [PATCH v2 3/6] cpu-exec: Rename cpu_resume_from_signal() to cpu_loop_exit_noexc() Peter Maydell
2016-05-17 14:18 ` [Qemu-devel] [PATCH v2 4/6] user-exec: Don't reextract sigmask from usercontext pointer Peter Maydell
2016-05-17 14:18 ` [Qemu-devel] [PATCH v2 5/6] target-i386: Add comment about do_interrupt_user() next_eip argument Peter Maydell
2016-06-06 16:37 ` Sergey Fedorov
2016-05-17 14:18 ` [Qemu-devel] [PATCH v2 6/6] target-i386: Move user-mode exception actions out of user-exec.c Peter Maydell
2016-06-06 16:47 ` Sergey Fedorov
2016-06-06 14:55 ` [Qemu-devel] [PATCH v2 0/6] user-exec: cpu_resume_from_signal() cleanups Peter Maydell
2016-06-06 16:57 ` Peter Maydell
2016-06-06 19:25 ` Eduardo Habkost
2016-06-07 7:59 ` Riku Voipio [this message]
2016-06-09 15:28 ` Peter Maydell
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=20160607075930.GA19978@beaming.home \
--to=riku.voipio@iki.fi \
--cc=ehabkost@redhat.com \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=sergey.fedorov@linaro.org \
/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.