Re: [PATCH v4 03/14] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched EL0 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux