RE: [PATCH v13 26/35] x86/fred: FRED entry/exit and dispatch code
> > In my opinion, cross-checking is the better approach, because it means that
> > violations of the assumptions get noticed more quickly, and hopefully by
> > whomever is working on the new feature which alters the assumptions.
>
> Yeah, I can make the change.
Hi Andrew,
Following is the updated patch, can you please have another review?
Thanks!
Xin
diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c
new file mode 100644
index ..fd36fb8d2a19
--- /dev/null
+++ b/arch/x86/entry/entry_fred.c
@@ -0,0 +1,252 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * The FRED specific kernel/user entry functions which are invoked from
+ * assembly code and dispatch to the associated handlers.
+ */
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* FRED EVENT_TYPE_OTHER vector numbers */
+#define FRED_SYSCALL 1
+#define FRED_SYSENTER 2
+
+static noinstr void fred_bad_type(struct pt_regs *regs, unsigned long
error_code)
+{
+ irqentry_state_t irq_state = irqentry_nmi_enter(regs);
+
+ instrumentation_begin();
+
+ /* Panic on events from a high stack level */
+ if (regs->fred_cs.sl > 0) {
+ pr_emerg("PANIC: invalid or fatal FRED event; event type %u "
+"vector %u error 0x%lx aux 0x%lx at %04x:%016lx\n",
+regs->fred_ss.type, regs->fred_ss.vector,
regs->orig_ax,
+fred_event_data(regs), regs->cs, regs->ip);
+ die("invalid or fatal FRED event", regs, regs->orig_ax);
+ panic("invalid or fatal FRED event");
+ } else {
+ unsigned long flags = oops_begin();
+ int sig = SIGKILL;
+
+ pr_alert("BUG: invalid or fatal FRED event; event type %u "
+"vector %u error 0x%lx aux 0x%lx at %04x:%016lx\n",
+regs->fred_ss.type, regs->fred_ss.vector,
regs->orig_ax,
+fred_event_data(regs), regs->cs, regs->ip);
+
+ if (__die("Invalid or fatal FRED event", regs, regs->orig_ax))
+ sig = 0;
+
+ oops_end(flags, regs, sig);
+ }
+
+ instrumentation_end();
+ irqentry_nmi_exit(regs, irq_state);
+}
+
+static noinstr void fred_intx(struct pt_regs *regs)
+{
+ switch (regs->fred_ss.vector) {
+ /* Opcode 0xcd, 0x3, NOT INT3 (opcode 0xcc) */
+ case X86_TRAP_BP:
+ exc_int3(regs);
+ return;
+
+ /* Opcode 0xcd, 0x4, NOT INTO (opcode 0xce) */
+ case X86_TRAP_OF:
+ exc_overflow(regs);
+ return;
+
+ /* INT80 */
+ case IA32_SYSCALL_VECTOR:
+ if (ia32_enabled()) {
+ /* Save the syscall number */
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_int80_syscall_32(regs);
+ return;
+ }
+ fallthrough;
+
+ default:
+ exc_general_protection(regs, 0);
+ return;
+ }
+}
+
+static __always_inline void fred_other(struct pt_regs *regs)
+{
+ /* The compiler can fold these conditions into a single test */
+ if (likely(regs->fred_ss.vector == FRED_SYSCALL && regs->fred_ss.lm)) {
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_syscall_64(regs, regs->orig_ax);
+ return;
+ } else if (ia32_enabled() &&
+ likely(regs->fred_ss.vector == FRED_SYSENTER &&
+ !regs->fred_ss.lm)) {
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_fast_syscall_32(regs);
+ return;
+ } else {
+ exc_invalid_op(regs);
+ return;
+ }
+}
+
+#define SYSVEC(_vector, _function) [_vector - FIRST_SYSTEM_VECTOR] =
fred_sysvec_##_function
+
+static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init = {
+ SYSVEC(ERROR_APIC_VECTOR, error_interrupt),
+ SYSVEC(SPURIOUS_APIC_VECTOR,spurious_apic_interrupt),
+ SYSVEC(LOCAL_TIMER_VECTOR, apic_timer_interrupt),
+ SYSVEC(X86_PLATFORM_IPI_VECTOR, x86_platform_ipi),
+
+ SYSVEC(RESCHEDULE_VECTOR, reschedule_ipi),
+ SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, call_function_single),
+ SYSVEC(CALL_FUNCTION_VECTOR,call_function),
+ SYSVEC(REBOOT_VECTOR, reboot),
+
+ SYSVEC(THRESHOLD_APIC_VECTOR, threshold),
+ SYSVEC(DEFERRED_ERROR_VECTOR, deferred_error),
+ SYSVEC(THERMAL_APIC_VECTOR, thermal),
+
+ SYSVEC(IRQ_WORK_VECTOR, irq_work),
+
+ SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi),
+ SYSVEC(
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote: > Hi Simon, > > Thank you for the patch. > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > Add a script which produces a Flat Image Tree (FIT), a single file > > containing the built kernel and associated devicetree files. > > Compression defaults to gzip which gives a good balance of size and > > performance. > > > > The files compress from about 86MB to 24MB using this approach. > > > > The FIT can be used by bootloaders which support it, such as U-Boot > > and Linuxboot. It permits automatic selection of the correct > > devicetree, matching the compatible string of the running board with > > the closest compatible string in the FIT. There is no need for > > filenames or other workarounds. > > > > Add a 'make image.fit' build target for arm64, as well. Use > > FIT_COMPRESSION to select a different algorithm. > > > > The FIT can be examined using 'dumpimage -l'. > > > > This features requires pylibfdt (use 'pip install libfdt'). It also > > requires compression utilities for the algorithm being used. Supported > > compression options are the same as the Image.xxx files. For now there > > is no way to change the compression other than by editing the rule for > > $(obj)/image.fit > > > > While FIT supports a ramdisk / initrd, no attempt is made to support > > this here, since it must be built separately from the Linux build. > > FIT images are very useful, so I think this is a very welcome addition > to the kernel build system. It can get tricky though: given the > versatile nature of FIT images, there can't be any > one-size-fits-them-all solution to build them, and striking the right > balance between what makes sense for the kernel and the features that > users may request will probably lead to bikeshedding. As we all love > bikeshedding, I thought I would start selfishly, with a personal use > case :-) This isn't a yak-shaving request though, I don't see any reason > to delay merging this series. > > Have you envisioned building FIT images with a subset of DTBs, or adding > DTBOs ? Both would be fairly trivial extensions to this script by > extending the supported command line arguments. It would perhaps be more > difficult to integrate in the kernel build system though. This leads me > to a second question: would you consider merging extensions to this > script if they are not used by the kernel build system, but meant for > users who manually invoke the script ? More generally, is the script We'd also be interested in some customization, though in a different way. We imagine having a rule file that says X compatible string should map to A base DTB, plus B and C DTBO for the configuration section. The base DTB would carry all common elements of some device, while the DTBOs carry all the possible second source components, like different display panels or MIPI cameras for instance. This could drastically reduce the size of FIT images in ChromeOS by deduplicating all the common stuff. > meant to be used stand-alone as well, in which case its command line > arguments need to remain backward-compatible, or do you see it as being > internal to the kernel ? [...] ChenYu
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote: > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote: > > Hi Simon, > > > > Thank you for the patch. > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > > Add a script which produces a Flat Image Tree (FIT), a single file > > > containing the built kernel and associated devicetree files. > > > Compression defaults to gzip which gives a good balance of size and > > > performance. > > > > > > The files compress from about 86MB to 24MB using this approach. > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot > > > and Linuxboot. It permits automatic selection of the correct > > > devicetree, matching the compatible string of the running board with > > > the closest compatible string in the FIT. There is no need for > > > filenames or other workarounds. > > > > > > Add a 'make image.fit' build target for arm64, as well. Use > > > FIT_COMPRESSION to select a different algorithm. > > > > > > The FIT can be examined using 'dumpimage -l'. > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also > > > requires compression utilities for the algorithm being used. Supported > > > compression options are the same as the Image.xxx files. For now there > > > is no way to change the compression other than by editing the rule for > > > $(obj)/image.fit > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support > > > this here, since it must be built separately from the Linux build. > > > > FIT images are very useful, so I think this is a very welcome addition > > to the kernel build system. It can get tricky though: given the > > versatile nature of FIT images, there can't be any > > one-size-fits-them-all solution to build them, and striking the right > > balance between what makes sense for the kernel and the features that > > users may request will probably lead to bikeshedding. As we all love > > bikeshedding, I thought I would start selfishly, with a personal use > > case :-) This isn't a yak-shaving request though, I don't see any reason > > to delay merging this series. > > > > Have you envisioned building FIT images with a subset of DTBs, or adding > > DTBOs ? Both would be fairly trivial extensions to this script by > > extending the supported command line arguments. It would perhaps be more > > difficult to integrate in the kernel build system though. This leads me > > to a second question: would you consider merging extensions to this > > script if they are not used by the kernel build system, but meant for > > users who manually invoke the script ? More generally, is the script > > We'd also be interested in some customization, though in a different way. > We imagine having a rule file that says X compatible string should map > to A base DTB, plus B and C DTBO for the configuration section. The base > DTB would carry all common elements of some device, while the DTBOs > carry all the possible second source components, like different display > panels or MIPI cameras for instance. This could drastically reduce the > size of FIT images in ChromeOS by deduplicating all the common stuff. Do you envision the "mapping" compatible string mapping to a config section in the FIT image, that would bundle the base DTB and the DTBOs ? > > meant to be used stand-alone as well, in which case its command line > > arguments need to remain backward-compatible, or do you see it as being > > internal to the kernel ? > > [...] > > ChenYu -- Regards, Laurent Pinchart
Re: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
On Sun, 03 Dec 2023 18:46:22 +0100, Krzysztof Kozlowski wrote:
> Document preferred coding style for Devicetree sources (DTS and DTSI),
> to bring consistency among all (sub)architectures and ease in reviews.
>
> Cc: Andrew Davis
> cc: Andrew Lunn
> Cc: AngeloGioacchino Del Regno
> Cc: Arnd Bergmann
> Cc: Bjorn Andersson
> Cc: Chen-Yu Tsai
> Cc: Dmitry Baryshkov
> Cc: Jonathan Corbet
> Cc: Matthias Brugger
> Cc: Michal Simek
> Cc: Neil Armstrong
> Cc: Nishanth Menon
> Cc: Olof Johansson
> Cc: Rafał Miłecki
> Acked-by: Neil Armstrong
> Acked-by: Heiko Stuebner
> Reviewed-by: Laurent Pinchart
> Acked-by: Konrad Dybcio
> Reviewed-by: Geert Uytterhoeven
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Merging idea: Rob/DT bindings
>
> Changes in v4
> =
> 1. Drop label at the top (Jon)
> 2. Grammar fixes (Laurent, Dragan)
> 3. "Unless a bus defines differently, unit addresses shall ..." (Rob)
> 4. Use hex in example of dma-controller (Andrew)
> 5. Example: soc@ -> soc@0
> 6. Reverse points 2 and 3 in "Indentation" (Andrew)
> 7. Use full path to coding style doc (Conor)
>
> Changes in v3
> =
> 1. should->shall (Angelo)
> 2. Comments // -> /* (Angelo, Michal)
> 3. Use imaginary example in "Order of Properties in Device Node"
>(Angelo)
> 4. Added paragraphs for three sections with justifications of chosen
>style.
> 5. Allow two style of ordering overrides in board DTS: alphabetically or
>by order of DTSI (Rob).
> 6. I did not incorporate feedback about, due to lack of consensus and my
>disagreement:
>a. SoM being DTS without DTSI in "Organizing DTSI and DTS"
>
> Changes in v2
> =
> 1. Hopefully incorporate entire feedback from comments:
> a. Fix \ { => / { (Rob)
> b. Name: dts-coding-style (Rob)
> c. Exceptions for ordering nodes by name for Renesas and pinctrl (Geert,
>Konrad)
> d. Ordering properties by common/vendor (Rob)
> e. Array entries in <> (Rob)
>
> 2. New chapter: Organizing DTSI and DTS
>
> 3. Several grammar fixes (missing articles)
>
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: workfl...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> ---
> .../devicetree/bindings/dts-coding-style.rst | 196 ++
> Documentation/devicetree/bindings/index.rst | 1 +
> 2 files changed, 197 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dts-coding-style.rst
>
I added the quotes as discussed and applied, thanks!
Rob
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
Hi, On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote: > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote: > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote: > > > Hi Simon, > > > > > > Thank you for the patch. > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > > > Add a script which produces a Flat Image Tree (FIT), a single file > > > > containing the built kernel and associated devicetree files. > > > > Compression defaults to gzip which gives a good balance of size and > > > > performance. > > > > > > > > The files compress from about 86MB to 24MB using this approach. > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot > > > > and Linuxboot. It permits automatic selection of the correct > > > > devicetree, matching the compatible string of the running board with > > > > the closest compatible string in the FIT. There is no need for > > > > filenames or other workarounds. > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use > > > > FIT_COMPRESSION to select a different algorithm. > > > > > > > > The FIT can be examined using 'dumpimage -l'. > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also > > > > requires compression utilities for the algorithm being used. Supported > > > > compression options are the same as the Image.xxx files. For now there > > > > is no way to change the compression other than by editing the rule for > > > > $(obj)/image.fit > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support > > > > this here, since it must be built separately from the Linux build. > > > > > > FIT images are very useful, so I think this is a very welcome addition > > > to the kernel build system. It can get tricky though: given the > > > versatile nature of FIT images, there can't be any > > > one-size-fits-them-all solution to build them, and striking the right > > > balance between what makes sense for the kernel and the features that > > > users may request will probably lead to bikeshedding. As we all love > > > bikeshedding, I thought I would start selfishly, with a personal use > > > case :-) This isn't a yak-shaving request though, I don't see any reason > > > to delay merging this series. > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding > > > DTBOs ? Both would be fairly trivial extensions to this script by > > > extending the supported command line arguments. It would perhaps be more > > > difficult to integrate in the kernel build system though. This leads me > > > to a second question: would you consider merging extensions to this > > > script if they are not used by the kernel build system, but meant for > > > users who manually invoke the script ? More generally, is the script > > > > We'd also be interested in some customization, though in a different way. > > We imagine having a rule file that says X compatible string should map > > to A base DTB, plus B and C DTBO for the configuration section. The base > > DTB would carry all common elements of some device, while the DTBOs > > carry all the possible second source components, like different display > > panels or MIPI cameras for instance. This could drastically reduce the > > size of FIT images in ChromeOS by deduplicating all the common stuff. > > Do you envision the "mapping" compatible string mapping to a config > section in the FIT image, that would bundle the base DTB and the DTBOs ? > > > > meant to be used stand-alone as well, in which case its command line > > > arguments need to remain backward-compatible, or do you see it as being > > > internal to the kernel ? It is great to see all this discussion! I did send a proposal to the U-Boot ML about extensions but it was mixed up with other things, so I'll start a new thread. For now, I am really just waiting for this to be applied, before talking too much about future possibilities. Regards, SImon
Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree
On Thu, Dec 07, 2023 at 01:52:53PM -0700, Simon Glass wrote: > On Thu, 7 Dec 2023 at 07:38, Laurent Pinchart wrote: > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote: > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote: > > > > Hi Simon, > > > > > > > > Thank you for the patch. > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote: > > > > > Add a script which produces a Flat Image Tree (FIT), a single file > > > > > containing the built kernel and associated devicetree files. > > > > > Compression defaults to gzip which gives a good balance of size and > > > > > performance. > > > > > > > > > > The files compress from about 86MB to 24MB using this approach. > > > > > > > > > > The FIT can be used by bootloaders which support it, such as U-Boot > > > > > and Linuxboot. It permits automatic selection of the correct > > > > > devicetree, matching the compatible string of the running board with > > > > > the closest compatible string in the FIT. There is no need for > > > > > filenames or other workarounds. > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. Use > > > > > FIT_COMPRESSION to select a different algorithm. > > > > > > > > > > The FIT can be examined using 'dumpimage -l'. > > > > > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It also > > > > > requires compression utilities for the algorithm being used. Supported > > > > > compression options are the same as the Image.xxx files. For now there > > > > > is no way to change the compression other than by editing the rule for > > > > > $(obj)/image.fit > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to support > > > > > this here, since it must be built separately from the Linux build. > > > > > > > > FIT images are very useful, so I think this is a very welcome addition > > > > to the kernel build system. It can get tricky though: given the > > > > versatile nature of FIT images, there can't be any > > > > one-size-fits-them-all solution to build them, and striking the right > > > > balance between what makes sense for the kernel and the features that > > > > users may request will probably lead to bikeshedding. As we all love > > > > bikeshedding, I thought I would start selfishly, with a personal use > > > > case :-) This isn't a yak-shaving request though, I don't see any reason > > > > to delay merging this series. > > > > > > > > Have you envisioned building FIT images with a subset of DTBs, or adding > > > > DTBOs ? Both would be fairly trivial extensions to this script by > > > > extending the supported command line arguments. It would perhaps be more > > > > difficult to integrate in the kernel build system though. This leads me > > > > to a second question: would you consider merging extensions to this > > > > script if they are not used by the kernel build system, but meant for > > > > users who manually invoke the script ? More generally, is the script > > > > > > We'd also be interested in some customization, though in a different way. > > > We imagine having a rule file that says X compatible string should map > > > to A base DTB, plus B and C DTBO for the configuration section. The base > > > DTB would carry all common elements of some device, while the DTBOs > > > carry all the possible second source components, like different display > > > panels or MIPI cameras for instance. This could drastically reduce the > > > size of FIT images in ChromeOS by deduplicating all the common stuff. > > > > Do you envision the "mapping" compatible string mapping to a config > > section in the FIT image, that would bundle the base DTB and the DTBOs ? > > > > > > meant to be used stand-alone as well, in which case its command line > > > > arguments need to remain backward-compatible, or do you see it as being > > > > internal to the kernel ? > > It is great to see all this discussion! I did send a proposal to the > U-Boot ML about extensions but it was mixed up with other things, so > I'll start a new thread. > > For now, I am really just waiting for this to be applied, before > talking too much about future possibilities. Sure, I don't see any reason to delay this series until you have fixed everybody's system images problems :-) -- Regards, Laurent Pinchart
Re: [PATCH v4] docs: dt-bindings: add DTS Coding Style document
On 12/3/2023 9:46 AM, Krzysztof Kozlowski wrote: Document preferred coding style for Devicetree sources (DTS and DTSI), to bring consistency among all (sub)architectures and ease in reviews. Cc: Andrew Davis cc: Andrew Lunn Cc: AngeloGioacchino Del Regno Cc: Arnd Bergmann Cc: Bjorn Andersson Cc: Chen-Yu Tsai Cc: Dmitry Baryshkov Cc: Jonathan Corbet Cc: Matthias Brugger Cc: Michal Simek Cc: Neil Armstrong Cc: Nishanth Menon Cc: Olof Johansson Cc: Rafał Miłecki Acked-by: Neil Armstrong Acked-by: Heiko Stuebner Reviewed-by: Laurent Pinchart Acked-by: Konrad Dybcio Reviewed-by: Geert Uytterhoeven Signed-off-by: Krzysztof Kozlowski Reviewed-by: Florian Fainelli -- Florian
