From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64/cpuinfo: Drop boot_cpu_data
Date: Mon, 4 May 2020 20:23:08 +0530 [thread overview]
Message-ID: <224296d1-086a-5516-95a8-8f4ad5c533d9@arm.com> (raw)
In-Reply-To: <20200504124321.GA73375@C02TD0UTHF1T.local>
On 05/04/2020 06:13 PM, Mark Rutland wrote:
> On Mon, May 04, 2020 at 06:00:00PM +0530, Anshuman Khandual wrote:
>> A global boot_cpu_data is not really required. Lets drop this.
>
> I don't think it's true that this isn't required today.
>
> One reason that we have both boot_cpu_data and a cpu_data variable for
> CPU0 is that CPU0 itself can be hotplugged out then back in, and this
> allows us to detect if CPU0's features have changed (e.g. due to FW
> failing to configure it appropriately, or real physical hotplug
> occurring).
Understood. After hotplug, CPU0 will come back via secondary_start_kernel()
where it's current register values will be checked against earlier captured
values i.e boot_cpu_data.
But wondering why should CPU0 be treated like any other secondary CPU. IOW
in case the fresh boot CPU register values dont match with boot_cpu_data,
should not the online process just be declined ? AFAICS, current approach
will let the kernel run with taint in case of a mismatch.
>
> So NAK to the patch as it stands. If we're certain we capture all of
> those details even without boot_cpu_data, then we should make other
> changes to make that clear (e.g. removing it as an argument to
> update_cpu_features()).
There might not be another way, unless we can override CPU0's cpu_data
variable when the boot CPU comes back in after vetting against existing
values. Is there any particular reason to store the very first boot CPU0
info for ever ?
Passing on CPU0's cpu_data variable in update_cpu_features() for secondary
CPUs during boot still make sense. It helps in finalizing register values.
Re-entering CPU0's test against boot_cpu_data seems different.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-04 14:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 12:30 [PATCH] arm64/cpuinfo: Drop boot_cpu_data Anshuman Khandual
2020-05-04 12:43 ` Mark Rutland
2020-05-04 14:53 ` Anshuman Khandual [this message]
2020-05-04 15:50 ` Mark Rutland
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=224296d1-086a-5516-95a8-8f4ad5c533d9@arm.com \
--to=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=suzuki.poulose@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