From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
qemu-ppc@nongnu.org, david@gibson.dropbear.id.au
Cc: alex.bennee@linaro.org, qemu-devel@nongnu.org, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH RFC] target-ppc: tlbie should have global effect
Date: Fri, 09 Sep 2016 15:00:04 +1000 [thread overview]
Message-ID: <1473397204.8689.154.camel@kernel.crashing.org> (raw)
In-Reply-To: <87h99p7kax.fsf@abhimanyu.i-did-not-set--mail-host-address--so-tickle-me>
On Fri, 2016-09-09 at 10:15 +0530, Nikunj A Dadhania wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> >
> > On Fri, 2016-09-09 at 09:53 +0530, Nikunj A Dadhania wrote:
> > >
> > > tlbie (and H_REMOVE for pseries) should have a global effect. This is
> > > achieved by iterating and setting tlb_need_flush in all the CPUs.
> > >
> > > > > > Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > > > > Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
> > >
> > > --
> > >
> > > Note: Haven't changed following POWERPC_MMU_32B and POWERPC_MMU_601
> > > yet.
> > > As I am not sure about it.
> >
> > 604 and 7400 can do SMP.
>
> Sure, will add similar logic there.
>
> >
> > That said, I think the approach in your patch is going to be a bit big
> > of a hammer.
>
> >
> > We should have a separate flag indicating that we need to
> > broadcast a flush and only set it on tlbie (non-l) and tlbivax (on
> > BookE) so that we don't end up doing expensive broadcasts on things
> > like context switches.
>
> I had implemented that initially, and was checking that in
> check_tlb_flush, the logic was getting complicated, so thought about
> this way.
>
> Moreover, I was thinking about it, that needs to be a global tcg flag
> and not part the CPUPPCState structure, I was then worried about how to
> synchronise a global tcg variable.
No it doesn't.
When a "broadcast TLB" op happens, such as tlbie, you set both flags.
The existing one which just means the current CPU needs flushing, that
logic doesnt' change at all.
The other one means that *this* CPU needs to broadcast a TLB inval,
thus it's also a local flag !
Then you change gen_check_tlb_flush() to take an argument (an immediate
value) which you set to 1 in ptesync on BookS and tlbsync on BookE and
leave 0 on all the others.
Finally, gen_check_tlb_flush() does what it does today, then *additionally*
if that argument was 1 *and* the broadcast_flush flag was set, the helper
can then shoot the invalidations to all the other CPUs (and clear the flag).
CPU_FOREACH(cs) {
if (cs != this_cpu) {
tlb_flush(...)
}
}
For MT-TCG, the only change is then in that the above loop does async
procesdure calls to the target CPUs.
You will need to make sure ptesync/tlbsync (the latter only on BookE, make
it a nop on BookS) also exit the TB which is easy to do so that we get
the synchronization with the pending async works as Paolo mentioned separately
(double check with him and/or Alex ot make sure you get that right).
> > We keep the existing logic to flush locally. We additionally replace
> > the one in ptesync (BookS) or tlbsync (BookE) to test for the broadcast
> > flag, and flush the "other" CPUs if set.
> >
> > That also means you have a nice spot to do the more complex MT-TCG
> > broadcast only when needed in the future.
> >
>
> Regards
> Nikunj
next prev parent reply other threads:[~2016-09-09 5:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 4:23 [Qemu-devel] [PATCH RFC] target-ppc: tlbie should have global effect Nikunj A Dadhania
2016-09-09 4:30 ` Benjamin Herrenschmidt
2016-09-09 4:45 ` Nikunj A Dadhania
2016-09-09 5:00 ` Benjamin Herrenschmidt [this message]
2016-09-09 5:03 ` Benjamin Herrenschmidt
2016-09-09 5:08 ` Nikunj A Dadhania
2016-09-09 5:49 ` 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=1473397204.8689.154.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=alex.bennee@linaro.org \
--cc=david@gibson.dropbear.id.au \
--cc=nikunj@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
/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.