From: Will Deacon <will.deacon@arm.com> To: Daniel Thompson <daniel.thompson@linaro.org> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <Catalin.Marinas@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "patches@linaro.org" <patches@linaro.org>, "linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>, John Stultz <john.stultz@linaro.org>, Sumit Semwal <sumit.semwal@linaro.org>, Marc Zyngier <Marc.Zyngier@arm.com>, Andrew Thoelke <Andrew.Thoelke@arm.com>, Dave P Martin <Dave.Martin@arm.com> Subject: Re: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Date: Thu, 17 Sep 2015 16:43:04 +0100 [thread overview] Message-ID: <20150917154304.GM25634@arm.com> (raw) In-Reply-To: <55FADC0B.9080200@linaro.org> On Thu, Sep 17, 2015 at 04:28:11PM +0100, Daniel Thompson wrote: > On 17/09/15 15:01, Will Deacon wrote: > > Sorry, I'm thinking slightly ahead of myself, but the series from Suzuki > > creates a shadow "safe" view of the ID registers in the system, > > corresponding to the intersection of CPU features: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/370386.html > > > > In this case, it is necessary to inspect all of the possible CPUs before > > we can apply the patching, but as I say above, I'm prepared to make an > > exception for NMI because I don't think we can assume a safe value anyway > > for a system with mismatched GIC CPU interfaces. I just don't want to > > drag all of the alternatives patching earlier as well. > > Thanks. I'll take a close look at this patch set and work out how to > cooperate with it. Brill, thanks. > However I would like, if I can, to persuade you that we are making an > exception ARM64_HAS_SYSREG_GIC_CPUIF rather than specifically for things > that are NMI related. Sure, I conflated the two above. > AFAIK all ARMv8 cores have a GIC_CPUIF and the system either has a GICv3+ > or it doesn't so it shouldn't matter what core you check the feature on; > it is in the nature of the feature we are detecting that it is safe to > patch early. I'm at all convinced that its not possible to build something with mismatched CPU interfaces, but that's not something we can support in Linux without significant rework of the GIC code, so we can ignore that possibility for now. > To some extent this is quibbling about semantics but: > > 1. Treating this as a general case will put us in a good position if we > ever have to deal with an errata that cannot wait until the system > has nearly finished booting. > > 2. It makes the resulting code very simple because we can just have a > bitmask indicating which cpufeatures we need should apply early and > which we apply late. That in turn means we don't have to > differentiate NMI alternatives from other alternatives (thus avoiding > a bunch of new alternative macros). > > I'm not seeking any kind binding agreement from you before you see the > patch but if you *know* right now that you would nack something that > follows the above thinking then please let me know so I don't waste time > writing it ;-) . If you're on the fence I'll happily write the patch and > you can see what I think then I don't object to the early patching if it's done on an opt-in basis for features that (a) really need it and (b) are guaranteed to work across the whole system for anything that Linux supports. Deal? I think it gives you the rope you need :) Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Date: Thu, 17 Sep 2015 16:43:04 +0100 [thread overview] Message-ID: <20150917154304.GM25634@arm.com> (raw) In-Reply-To: <55FADC0B.9080200@linaro.org> On Thu, Sep 17, 2015 at 04:28:11PM +0100, Daniel Thompson wrote: > On 17/09/15 15:01, Will Deacon wrote: > > Sorry, I'm thinking slightly ahead of myself, but the series from Suzuki > > creates a shadow "safe" view of the ID registers in the system, > > corresponding to the intersection of CPU features: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/370386.html > > > > In this case, it is necessary to inspect all of the possible CPUs before > > we can apply the patching, but as I say above, I'm prepared to make an > > exception for NMI because I don't think we can assume a safe value anyway > > for a system with mismatched GIC CPU interfaces. I just don't want to > > drag all of the alternatives patching earlier as well. > > Thanks. I'll take a close look at this patch set and work out how to > cooperate with it. Brill, thanks. > However I would like, if I can, to persuade you that we are making an > exception ARM64_HAS_SYSREG_GIC_CPUIF rather than specifically for things > that are NMI related. Sure, I conflated the two above. > AFAIK all ARMv8 cores have a GIC_CPUIF and the system either has a GICv3+ > or it doesn't so it shouldn't matter what core you check the feature on; > it is in the nature of the feature we are detecting that it is safe to > patch early. I'm at all convinced that its not possible to build something with mismatched CPU interfaces, but that's not something we can support in Linux without significant rework of the GIC code, so we can ignore that possibility for now. > To some extent this is quibbling about semantics but: > > 1. Treating this as a general case will put us in a good position if we > ever have to deal with an errata that cannot wait until the system > has nearly finished booting. > > 2. It makes the resulting code very simple because we can just have a > bitmask indicating which cpufeatures we need should apply early and > which we apply late. That in turn means we don't have to > differentiate NMI alternatives from other alternatives (thus avoiding > a bunch of new alternative macros). > > I'm not seeking any kind binding agreement from you before you see the > patch but if you *know* right now that you would nack something that > follows the above thinking then please let me know so I don't waste time > writing it ;-) . If you're on the fence I'll happily write the patch and > you can see what I think then I don't object to the early patching if it's done on an opt-in basis for features that (a) really need it and (b) are guaranteed to work across the whole system for anything that Linux supports. Deal? I think it gives you the rope you need :) Will
next prev parent reply other threads:[~2015-09-17 15:43 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-09-14 13:26 [RFC PATCH v2 0/7] Pseudo-NMI for arm64 using ICC_PMR_EL1 (GICv3) Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 1/7] irqchip: gic-v3: Reset BPR during initialization Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 2/7] arm64: Add support for on-demand backtrace of other CPUs Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 3/7] arm64: alternative: Apply alternatives early in boot process Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-16 13:05 ` Will Deacon 2015-09-16 13:05 ` Will Deacon 2015-09-16 15:51 ` Daniel Thompson 2015-09-16 15:51 ` Daniel Thompson 2015-09-16 16:24 ` Will Deacon 2015-09-16 16:24 ` Will Deacon 2015-09-17 13:25 ` Daniel Thompson 2015-09-17 13:25 ` Daniel Thompson 2015-09-17 14:01 ` Will Deacon 2015-09-17 14:01 ` Will Deacon 2015-09-17 15:28 ` Daniel Thompson 2015-09-17 15:28 ` Daniel Thompson 2015-09-17 15:43 ` Will Deacon [this message] 2015-09-17 15:43 ` Will Deacon 2015-09-14 13:26 ` [RFC PATCH v2 4/7] arm64: irqflags: Reorder the fiq & async macros Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 5/7] arm64: irqflags: Use ICC sysregs to implement IRQ masking Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 6/7] arm64: Implement IPI_CPU_BACKTRACE using pseudo-NMIs Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-14 13:26 ` [RFC PATCH v2 7/7] arm64: irqflags: Automatically identify I bit mis-management Daniel Thompson 2015-09-14 13:26 ` Daniel Thompson 2015-09-18 5:11 ` [RFC PATCH v2 0/7] Pseudo-NMI for arm64 using ICC_PMR_EL1 (GICv3) Jon Masters 2015-09-18 5:11 ` Jon Masters 2015-09-18 11:23 ` Daniel Thompson 2015-09-18 11:23 ` Daniel Thompson 2015-09-22 18:08 ` 答复: " Dingtianhong
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=20150917154304.GM25634@arm.com \ --to=will.deacon@arm.com \ --cc=Andrew.Thoelke@arm.com \ --cc=Catalin.Marinas@arm.com \ --cc=Dave.Martin@arm.com \ --cc=Marc.Zyngier@arm.com \ --cc=daniel.thompson@linaro.org \ --cc=john.stultz@linaro.org \ --cc=linaro-kernel@lists.linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=patches@linaro.org \ --cc=sumit.semwal@linaro.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.