On 2020-12-01 16:57, Will Deacon wrote:
On Fri, Nov 27, 2020 at 06:16:35PM +0000, Marc Zyngier wrote:
On 2020-11-27 17:24, Quentin Perret wrote:
> On Friday 27 Nov 2020 at 17:14:11 (+0000), Marc Zyngier wrote:
[...]
> > Yeah, the sanitized read feels better, if only because that is
> > what we are going to read in all the valid cases, unfortunately.
> > read_sanitised_ftr_reg() is sadly not designed to be called on
> > a fast path, meaning that 32bit guests will do a bsearch() on
> > the ID-regs every time they exit...
> >
> > I guess we will have to evaluate how much we loose with this.
>
> Could we use the trick we have for arm64_ftr_reg_ctrel0 to speed this
> up?
Maybe. I want to first verify whether this has any measurable impact.
Another possibility would be to cache the last
read_sanitised_ftr_reg()
access, just to see if that helps. There shouldn't be that many code
paths hammering it.
We don't have huge numbers of ID registers, so the bsearch shouldn't be
too expensive. However, I'd like to remind myself why we can't index
into
the feature register array directly as we _should_ know all of this
stuff
at compile time, right?
Simply because it's not indexed by ID reg. It's just an ordered
collection,
similar to the for sys_reg emulation in KVM. You can compute the index
ahead of time, but just not at compile time. At least not with the
way the arm64_ftr_regs array is built.
M.
--
Jazz is not dead. It just smells funny...
