linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: afzal.mohd.ma@gmail.com (afzal mohammed)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
Date: Wed, 20 Dec 2017 17:19:24 +0530	[thread overview]
Message-ID: <20171220114924.GA5377@afzalpc> (raw)
In-Reply-To: <b0e23a0b-8488-b1bc-8afe-cd68e47b9ad6@arm.com>

Hi,

On Wed, Dec 20, 2017 at 09:55:00AM +0000, Vladimir Murzin wrote:

> >> I caught it when was trying to setup VBAR and after code inspection I
> >> noticed that setting of Hivecs were changed as well.
> > 
> > Thinking again about this, should the Hivecs setting on secondary
> > CPU's be done (till a requirement comes) ?
> > 
> > ARM ARM deprecates using Hivecs setting on ARMv7-R, so this issue
> > might not be hit in practice for R class. While pre-ARMv7, lack of
> > Hivecs setting for secondaries, it seems can affect only ARMv6k
> > (multi-processing support added here ?) and i am making a guess that
> > even if there are ARMv6k with more than one core available, they might
> > not yet have run with MMU disabled to hit this case, probably the
> > reason no one has reported issue for long.
> 
> I've just reported an issue, no? :)

By reported, i meant whether the lack of this in secondary would cause
an issue at run time in any of the platform's. You spotted it by code
inspection rather than hitting any issue in practice is what i
understood.

> > Perhaps, we can avoid configuring Hivecs for secondaries until some
> > one needs it ?
> 
> Well, before ad475117d201, Hivec would be enabled for secondaries via
> 
> secondary_startup
> 	-> __after_proc_init
> 
> after that commit it is not true, so it is kind of regression.

Something that was done before that commit not being done later
(though unintentionally) per se doesn't count as regression in my
opinion. But if any platform really needs to gets this done or
misbehaves due to my change, then certainly it has to be counted a
regression, which i believe is not the case here.

> 
> Additionally, patch is not about Hivec only, but VBAR as well and TBH I
> don't follow what is your proposal...

i was referring to the fact that vector remapping can't be done in
Cortex-R, as security extension is a requisite for this feature, which
Cortex-R don't have on ARMv7.

afzal

  reply	other threads:[~2017-12-20 11:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-19 10:23 [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores Vladimir Murzin
2017-12-19 11:29 ` afzal mohammed
2017-12-19 14:44   ` Vladimir Murzin
2017-12-20  4:52     ` afzal mohammed
2017-12-20  9:55       ` Vladimir Murzin
2017-12-20 11:49         ` afzal mohammed [this message]
2017-12-20 12:01           ` afzal mohammed
2017-12-20 12:22             ` Vladimir Murzin
2017-12-21  4:05               ` afzal mohammed
2017-12-20 12:12           ` afzal mohammed
2017-12-20 12:22           ` Vladimir Murzin
2017-12-21  3:44             ` afzal mohammed

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=20171220114924.GA5377@afzalpc \
    --to=afzal.mohd.ma@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).