From: Paul Mackerras <paulus@samba.org>
To: Alexander Graf <agraf@suse.de>
Cc: kvm list <kvm@vger.kernel.org>, kvm-ppc <kvm-ppc@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 2/2] KVM: PPC: Book3S: Call into C interrupt handlers
Date: Fri, 27 Apr 2012 05:48:10 +0000 [thread overview]
Message-ID: <20120427054810.GC1216@drongo> (raw)
In-Reply-To: <1335435543-19690-2-git-send-email-agraf@suse.de>
On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
> So switch the code over to call into the Linux C handlers from C code,
> speeding up everything along the way.
I have to say this patch makes me pretty uneasy. There are a few
things that look wrong to me, but more than that, it seems to me that
there would be a lot of careful thought needed to make sure that the
approach is bullet-proof.
The first thing is that you are filling in the registers, and in
particular r1, in a subroutine, so you are potentially making regs.r1
point to a stack frame that no longer exists by the time we look at it
inside do_IRQ or timer_interrupt. So, for example, a stack trace
could go completely off the rails at that point. Quite possibly gcc
will inline the kvmppc_fill_pt_regs function, which would probably
save you, but I don't think you should rely on that.
The second thing is, why do you save just r1, ip, msr, and lr? Why
those ones and no others? A performance monitor interrupt might well
decide to save all the registers away plus a stack trace, and to see
all the GPRs as 0 could be very confusing.
Thirdly, if preemption is enabled, it could well be that the interrupt
will wake up a higher priority task which should run before we
continue. On 64-bit you are probably saved by the soft_irq_enable
calls, which will (I think) call schedule() if a reschedule is
pending, but on 32-bit soft_irq_enable does nothing.
Fourthly, as Ben said, you should be setting regs->trap.
Have you measured a performance improvement with this patch? If so
how big was it?
Paul.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mackerras <paulus@samba.org>
To: Alexander Graf <agraf@suse.de>
Cc: kvm list <kvm@vger.kernel.org>, kvm-ppc <kvm-ppc@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH 2/2] KVM: PPC: Book3S: Call into C interrupt handlers
Date: Fri, 27 Apr 2012 15:48:10 +1000 [thread overview]
Message-ID: <20120427054810.GC1216@drongo> (raw)
In-Reply-To: <1335435543-19690-2-git-send-email-agraf@suse.de>
On Thu, Apr 26, 2012 at 12:19:03PM +0200, Alexander Graf wrote:
> So switch the code over to call into the Linux C handlers from C code,
> speeding up everything along the way.
I have to say this patch makes me pretty uneasy. There are a few
things that look wrong to me, but more than that, it seems to me that
there would be a lot of careful thought needed to make sure that the
approach is bullet-proof.
The first thing is that you are filling in the registers, and in
particular r1, in a subroutine, so you are potentially making regs.r1
point to a stack frame that no longer exists by the time we look at it
inside do_IRQ or timer_interrupt. So, for example, a stack trace
could go completely off the rails at that point. Quite possibly gcc
will inline the kvmppc_fill_pt_regs function, which would probably
save you, but I don't think you should rely on that.
The second thing is, why do you save just r1, ip, msr, and lr? Why
those ones and no others? A performance monitor interrupt might well
decide to save all the registers away plus a stack trace, and to see
all the GPRs as 0 could be very confusing.
Thirdly, if preemption is enabled, it could well be that the interrupt
will wake up a higher priority task which should run before we
continue. On 64-bit you are probably saved by the soft_irq_enable
calls, which will (I think) call schedule() if a reschedule is
pending, but on 32-bit soft_irq_enable does nothing.
Fourthly, as Ben said, you should be setting regs->trap.
Have you measured a performance improvement with this patch? If so
how big was it?
Paul.
next prev parent reply other threads:[~2012-04-27 5:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-26 10:19 [PATCH 1/2] PPC: Export some interrupt handlers Alexander Graf
2012-04-26 10:19 ` Alexander Graf
2012-04-26 10:19 ` [PATCH 2/2] KVM: PPC: Book3S: Call into C " Alexander Graf
2012-04-26 10:19 ` Alexander Graf
2012-04-26 21:45 ` Benjamin Herrenschmidt
2012-04-26 21:45 ` Benjamin Herrenschmidt
2012-04-26 22:24 ` Alexander Graf
2012-04-26 22:24 ` Alexander Graf
2012-04-26 23:12 ` Benjamin Herrenschmidt
2012-04-26 23:12 ` Benjamin Herrenschmidt
2012-04-26 23:30 ` Alexander Graf
2012-04-26 23:30 ` Alexander Graf
2012-04-26 23:37 ` Benjamin Herrenschmidt
2012-04-26 23:37 ` Benjamin Herrenschmidt
2012-04-26 23:50 ` Alexander Graf
2012-04-26 23:50 ` Alexander Graf
2012-04-27 0:00 ` Benjamin Herrenschmidt
2012-04-27 0:00 ` Benjamin Herrenschmidt
2012-04-26 21:54 ` Scott Wood
2012-04-26 21:54 ` Scott Wood
2012-04-26 22:26 ` Alexander Graf
2012-04-26 22:26 ` Alexander Graf
2012-04-26 22:58 ` Benjamin Herrenschmidt
2012-04-26 22:58 ` Benjamin Herrenschmidt
2012-04-27 5:48 ` Paul Mackerras [this message]
2012-04-27 5:48 ` Paul Mackerras
2012-04-27 11:23 ` Alexander Graf
2012-04-27 11:23 ` Alexander Graf
2012-04-27 14:19 ` Alexander Graf
2012-04-27 14:19 ` Alexander Graf
2012-04-27 16:37 ` Scott Wood
2012-04-27 16:37 ` Scott Wood
2012-04-27 16:54 ` Alexander Graf
2012-04-27 16:54 ` Alexander Graf
2012-04-27 22:20 ` Benjamin Herrenschmidt
2012-04-27 22:20 ` Benjamin Herrenschmidt
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=20120427054810.GC1216@drongo \
--to=paulus@samba.org \
--cc=agraf@suse.de \
--cc=benh@kernel.crashing.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.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.