From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: context: Fix ASID limit in boot warning
Date: Tue, 25 Feb 2020 13:13:43 +0100 [thread overview]
Message-ID: <20200225121343.GD375953@myrica> (raw)
In-Reply-To: <a54c1498-2fff-8d97-5220-e378966d3853@arm.com>
Hi Vladimir,
On Mon, Feb 24, 2020 at 11:06:43AM +0000, Vladimir Murzin wrote:
> > static int asids_init(void)
> > {
> > + unsigned long num_available_asids;
> > + bool kpti = IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0);
> > +
> > asid_bits = get_cpu_asid_bits();
> > /*
> > * Expect allocation after rollover to fail if we don't have at least
> > * one more ASID than CPUs. ASID #0 is reserved for init_mm.
> > */
> > - WARN_ON(NUM_USER_ASIDS - 1 <= num_possible_cpus());
> > + num_available_asids = (1UL << (asid_bits - kpti)) - 1;
> > + WARN_ON(num_available_asids <= num_possible_cpus());
> > atomic64_set(&asid_generation, ASID_FIRST_VERSION);
> > asid_map = kcalloc(BITS_TO_LONGS(NUM_USER_ASIDS), sizeof(*asid_map),
> > GFP_KERNEL);
> > @@ -280,7 +284,7 @@ static int asids_init(void)
> > * caps are not finalized yet, so it is safer to assume KPTI
> > * and reserve kernel ASID's from beginning.
> > */
> > - if (IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0))
> > + if (kpti)
> > set_kpti_asid_bits();
> >
> > pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
> >
>
> I agree with what you say about NUM_USER_ASIDS, yet looking at comment explaining
> warning is seems that we may get extra ASIDs later on rollover, so warning might be
> seen as false positive. Can we move the warning later on when we know how many ASIDs
> we have after all CPU's are up?
Yes I think that's better. I've stumbled upon the issue when reworking my
ASID-pin patch [1], which will also need a precise maximum number of ASIDs
available.
> Maybe late_initcall?
I guess arch_initcall might be more appropriate. Any init level except
early should work since they are after smp_init().
Thanks,
Jean
[1] https://lore.kernel.org/linux-iommu/20200224182401.353359-8-jean-philippe@linaro.org/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2020-02-25 12:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-24 10:39 [PATCH] arm64: context: Fix ASID limit in boot warning Jean-Philippe Brucker
2020-02-24 11:06 ` Vladimir Murzin
2020-02-25 12:13 ` Jean-Philippe Brucker [this message]
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=20200225121343.GD375953@myrica \
--to=jean-philippe@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=vladimir.murzin@arm.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox