On 14.09.2023 08:03, Juergen Gross wrote:
> On 14.09.23 06:47, Xin Li wrote:
>> From: "H. Peter Anvin (Intel)"
>>
>> Any FRED CPU will always have the following features as its baseline:
>>1) LKGS, load attributes of the GS segment but the base address into
>> the IA32_KERNEL_GS_BASE MSR
On 14.09.23 06:47, Xin Li wrote:
From: "H. Peter Anvin (Intel)"
Any FRED CPU will always have the following features as its baseline:
1) LKGS, load attributes of the GS segment but the base address into
the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s descriptor
cache.
On 14.09.23 06:47, Xin Li wrote:
Add an always inline API __wrmsrns() to embed the WRMSRNS instruction
into the code.
Tested-by: Shan Kang
Signed-off-by: Xin Li
In order to avoid having to add paravirt support for WRMSRNS I think
xen_init_capabilities() should gain:
+ setup_clear_cpu_
From: "H. Peter Anvin (Intel)"
Add a syscall initialization function fred_syscall_init() for FRED,
and this is really just to skip setting up SYSCALL/SYSENTER related
MSRs, e.g., MSR_LSTAR and invalidate SYSENTER configurations, because
FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTE
From: "H. Peter Anvin (Intel)"
Add cpu_init_fred_exceptions() to:
- Set FRED entrypoints for events happening in ring 0 and 3.
- Specify the stack level for IRQs occurred ring 0.
- Specify dedicated event stacks for #DB/NMI/#MCE/#DF.
- Enable FRED and invalidtes IDT.
- Force 32-bit syst
From: "H. Peter Anvin (Intel)"
Let cpu_init_exception_handling() call cpu_init_fred_exceptions() to
initialize FRED. However if FRED is unavailable or disabled, it falls
back to set up TSS IST and initialize IDT.
Signed-off-by: H. Peter Anvin (Intel)
Co-developed-by: Xin Li
Tested-by: Shan Kan
Split IDT syscall setup code into idt_syscall_init() to make it
cleaner to add FRED syscall setup code.
Suggested-by: Thomas Gleixner
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/kernel/cpu/common.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/a
In IRQ/NMI induced VM exits, KVM VMX needs to execute the respective
handlers, which requires the software to create a FRED stack frame,
and use it to invoke the handlers. Add fred_irq_entry_from_kvm() for
this job.
Export fred_entry_from_kvm() because VMX can be compiled as a module.
Suggested-b
When FRED is enabled, call fred_entry_from_kvm() to handle IRQ/NMI in
IRQ/NMI induced VM exits.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/kvm/vmx/vmx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
From: "Peter Zijlstra (Intel)"
PUSH_AND_CLEAR_REGS could be used besides actual entry code; in that case
%rbp shouldn't be cleared (otherwise the frame pointer is destroyed) and
UNWIND_HINT shouldn't be added.
Signed-off-by: Peter Zijlstra (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
--
If the stack frame contains an invalid user context (e.g. due to invalid SS,
a non-canonical RIP, etc.) the ERETU instruction will trap (#SS or #GP).
>From a Linux point of view, this really should be considered a user space
failure, so use the standard fault fixup mechanism to intercept the fault
From: "H. Peter Anvin (Intel)"
Let ret_from_fork_asm() jmp to asm_fred_exit_user when FRED is enabled,
otherwise the existing IDT code is chosen.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/entry/entry_64.S | 6 ++
arch/x86/entry/ent
From: "H. Peter Anvin (Intel)"
Add sysvec_install() to install a system interrupt handler into the IDT
or the FRED system interrupt handler table.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v8:
* Introduce a macro sysvec_install() to derive the asm handler name from
a C ha
From: "H. Peter Anvin (Intel)"
The code to actually handle kernel and event entry/exit using
FRED. It is split up into two files thus:
- entry_64_fred.S contains the actual entrypoints and exit code, and
saves and restores registers.
- entry_fred.c contains the two-level event dispatch code fo
From: "H. Peter Anvin (Intel)"
When occurred on different ring level, i.e., from user or kernel context,
#DB needs to be handled on different stack: User #DB on current task
stack, while kernel #DB on a dedicated stack. This is exactly how FRED
event delivery invokes an exception handler: ring 3
Like #DB, when occurred on different ring level, i.e., from user or kernel
context, #MCE needs to be handled on different stack: User #MCE on current
task stack, while kernel #MCE on a dedicated stack.
This is exactly how FRED event delivery invokes an exception handler: ring
3 event on level 0 st
FRED and IDT can share most of the definitions and declarations so
that in the majority of cases the actual handler implementation is the
same.
The differences are the exceptions where FRED stores exception related
information on the stack and the sysvec implementations as FRED can
handle irqentry
From: "H. Peter Anvin (Intel)"
On a FRED system, NMIs nest both with themselves and faults, transient
information is saved into the stack frame, and NMI unblocking only
happens when the stack frame indicates that so should happen.
Thus, the NMI entry stub for FRED is really quite small...
Signe
From: "H. Peter Anvin (Intel)"
On a FRED system, the faulting address (CR2) is passed on the stack,
to avoid the problem of transient state. Thus we get the page fault
address from the stack instead of CR2.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Thomas Gleixn
From: "H. Peter Anvin (Intel)"
Because FRED always restores the full value of %rsp, ESPFIX is
no longer needed when it's enabled.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/kernel/espfix_64.c | 8
1 file changed, 8 insertions(+)
di
From: "H. Peter Anvin (Intel)"
Entering a new task is logically speaking a return from a system call
(exec, fork, clone, etc.). As such, if ptrace enables single stepping
a single step exception should be allowed to trigger immediately upon
entering user space. This is not optional.
NMI should *
From: "H. Peter Anvin (Intel)"
SWAPGS is no longer needed thus NOT allowed with FRED because FRED
transitions ensure that an operating system can _always_ operate
with its own GS base address:
- For events that occur in ring 3, FRED event delivery swaps the GS
base address with the IA32_KERNEL_
From: "H. Peter Anvin (Intel)"
When using FRED, reserve space at the top of the stack frame, just
like i386 does.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/thread_info.h | 12 +---
1 file changed, 9 insertions(+), 3 dele
From: "H. Peter Anvin (Intel)"
MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to
be updated to point to the top of next task stack during task switch.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/switch_to.h | 8
From: "H. Peter Anvin (Intel)"
Add a header file for FRED prototypes and definitions.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v6:
* Replace pt_regs csx flags prefix FRED_CSL_ with FRED_CSX_.
---
arch/x86/include/asm/fred.h | 68
FRED defines additional information in the upper 48 bits of cs/ss
fields. Therefore add the information definitions into the pt_regs
structure.
Specially introduce a new structure fred_ss to denote the FRED flags
above SS selector, which avoids FRED_SSX_ macros and makes the code
simpler and easie
struct pt_regs is hard to read because the member or section related
comments are not aligned with the members.
The 'cs' and 'ss' members of pt_regs are type of 'unsigned long' while
in reality they are only 16-bit wide. This works so far as the
remaining space is unused, but FRED will use the rem
From: "H. Peter Anvin (Intel)"
Add MSR numbers for the FRED configuration registers per FRED spec 5.0.
Originally-by: Megha Dey
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/msr-index.h | 13 -
tools/arch/x86/incl
From: "H. Peter Anvin (Intel)"
Update the objtool decoder to know about the ERET[US] instructions
(type INSN_CONTEXT_SWITCH).
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
tools/objtool/arch/x86/decode.c | 19 ++-
1 file changed, 14 inse
From: "H. Peter Anvin (Intel)"
ERETU returns from an event handler while making a transition to ring 3,
and ERETS returns from an event handler while staying in ring 0.
Add instruction opcodes used by ERET[US] to the x86 opcode map; opcode
numbers are per FRED spec v5.0.
Signed-off-by: H. Peter
From: "H. Peter Anvin (Intel)"
Add X86_CR4_FRED macro for the FRED bit in %cr4. This bit must not be
changed after initialization, so add it to the pinned CR4 bits.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Changes since v9:
* Avoid a type cast by d
To enable FRED, a new kernel command line option "fred" needs to be added.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
Documentation/admin-guide/kernel-parameters.txt | 3 +++
arch/x86/kernel/cpu/common.c| 3 +++
2 files changed, 6 insertions(+)
diff --git a/Documentatio
From: "H. Peter Anvin (Intel)"
Add CONFIG_X86_FRED to to make
cpu_feature_enabled() work correctly with FRED.
Originally-by: Megha Dey
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/disabled-features.h | 8 +++-
tools/arc
From: "H. Peter Anvin (Intel)"
Any FRED CPU will always have the following features as its baseline:
1) LKGS, load attributes of the GS segment but the base address into
the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s descriptor
cache.
2) WRMSRNS, non-serializing WRMSR for f
Briefly introduce FRED, and its advantages compared to IDT.
Signed-off-by: Xin Li
---
Documentation/arch/x86/x86_64/fred.rst | 98 +
Documentation/arch/x86/x86_64/index.rst | 1 +
2 files changed, 99 insertions(+)
create mode 100644 Documentation/arch/x86/x86_64/fred.r
Intel VT-x classifies events into eight different types, which is
inherited by FRED for event identification. As such, event type
becomes a common x86 concept, and should be defined in a common x86
header.
Add event type macros to , and use it in .
Suggested-by: H. Peter Anvin (Intel)
Tested-by:
From: "H. Peter Anvin (Intel)"
Add the configuration option CONFIG_X86_FRED to enable FRED.
Signed-off-by: H. Peter Anvin (Intel)
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/Kconfig | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
i
idtentry_sysvec is really just DECLARE_IDTENTRY defined in
, no need to define it separately.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/entry/entry_32.S | 4
arch/x86/entry/entry_64.S | 8
arch/x86/include/asm/idtentry.h | 2 +-
3 files changed, 1 inserti
Add an always inline API __wrmsrns() to embed the WRMSRNS instruction
into the code.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/include/asm/msr.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 65
Add the opcode used by WRMSRNS, which is the non-serializing version of
WRMSR and may replace it to improve performance, to the x86 opcode map.
Tested-by: Shan Kang
Signed-off-by: Xin Li
---
arch/x86/lib/x86-opcode-map.txt | 2 +-
tools/arch/x86/lib/x86-opcode-map.txt | 2 +-
2 files chan
This patch set enables the Intel flexible return and event delivery
(FRED) architecture for x86-64.
The FRED architecture defines simple new transitions that change
privilege level (ring transitions). The FRED architecture was
designed with the following goals:
1) Improve overall performance and
WRMSRNS is an instruction that behaves exactly like WRMSR, with
the only difference being that it is not a serializing instruction
by default. Under certain conditions, WRMSRNS may replace WRMSR to
improve performance.
Add the CPU feature bit for WRMSRNS.
Tested-by: Shan Kang
Signed-off-by: Xin
On Thu, Sep 14, 2023 at 4:49 AM Leonardo Bras wrote:
>
> On Wed, Sep 13, 2023 at 05:37:01PM -0300, Leonardo Bras wrote:
> > On Sun, Sep 10, 2023 at 07:06:23AM -0400, Guo Ren wrote:
> > > On Sun, Sep 10, 2023 at 04:29:00AM -0400, guo...@kernel.org wrote:
> > > > From: Guo Ren
> > > >
> > > > Combo
On Thu, Sep 14, 2023 at 4:29 AM Leonardo Bras wrote:
>
> On Sun, Sep 10, 2023 at 04:28:59AM -0400, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > The requirements of qspinlock have been documented by commit:
> > a8ad07e5240c ("asm-generic: qspinlock: Indicate the use of mixed-size
> > atomics
Hello Mark,
On Wed, Sep 13, 2023 at 4:57 PM Mark Brown wrote:
>
> While some subsystems do typically have very fast turnaround times on
> review this is far from standard over the kernel and is likely to set
> unrealistic expectations for submitters. Tell submitters to expect 2-3
> weeks instead
On Wed, Sep 13, 2023 at 9:06 PM Waiman Long wrote:
>
> On 9/13/23 08:52, Guo Ren wrote:
> > On Wed, Sep 13, 2023 at 4:55 PM Leonardo Bras wrote:
> >> On Tue, Sep 12, 2023 at 09:10:08AM +0800, Guo Ren wrote:
> >>> On Mon, Sep 11, 2023 at 9:03 PM Waiman Long wrote:
> On 9/10/23 23:09, Guo Ren
On Thu, Sep 14, 2023 at 2:54 AM Palmer Dabbelt wrote:
>
> On Sun, 06 Aug 2023 22:23:34 PDT (-0700), sor...@fastmail.com wrote:
> > On Wed, Aug 2, 2023, at 12:46 PM, guo...@kernel.org wrote:
> >> From: Guo Ren
> >>
> >> According to qspinlock requirements, RISC-V gives out a weak LR/SC
> >> forwar
On Wed, Sep 13, 2023 at 04:30:04PM -0700, Kees Cook wrote:
> On Mon, Sep 11, 2023 at 04:23:53PM +0530, Mukesh Ojha wrote:
> > Register all the pstore frontend with minidump, so that they can
> > be dumped as default Linux minidump region to be collected on
> > SoC where minidump is enabled.
> >
>
On Mon, Sep 11, 2023 at 04:23:53PM +0530, Mukesh Ojha wrote:
> Register all the pstore frontend with minidump, so that they can
> be dumped as default Linux minidump region to be collected on
> SoC where minidump is enabled.
>
> Helper functions is written in separate file and built along with
> t
On Mon, Sep 11, 2023 at 04:23:52PM +0530, Mukesh Ojha wrote:
> There are users like Qualcomm minidump which is interested in
> knowing the pstore frontend addresses and sizes from the backend
> (ram) to be able to register it with firmware to finally collect
> them during crash for debugging.
>
>
On Tue, Sep 12, 2023 at 11:18:20AM +0100, Will Deacon wrote:
> On Mon, Sep 11, 2023 at 04:23:50PM +0530, Mukesh Ojha wrote:
> > The reserved memory region for ramoops is assumed to be at a fixed
> > and known location when read from the devicetree. This may not be
> > required for something like Qu
On Wed, Sep 13, 2023 at 05:37:01PM -0300, Leonardo Bras wrote:
> On Sun, Sep 10, 2023 at 07:06:23AM -0400, Guo Ren wrote:
> > On Sun, Sep 10, 2023 at 04:29:00AM -0400, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > Combo spinlock could support queued and ticket in one Linux Image and
>
On Sun, Sep 10, 2023 at 07:06:23AM -0400, Guo Ren wrote:
> On Sun, Sep 10, 2023 at 04:29:00AM -0400, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Combo spinlock could support queued and ticket in one Linux Image and
> > select them during boot time via errata mechanism. Here is the func
> >
On Sun, Sep 10, 2023 at 04:28:59AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> The requirements of qspinlock have been documented by commit:
> a8ad07e5240c ("asm-generic: qspinlock: Indicate the use of mixed-size
> atomics").
>
> Although RISC-V ISA gives out a weaker forward guarantee L
On 9/13/23 14:54, Palmer Dabbelt wrote:
On Sun, 06 Aug 2023 22:23:34 PDT (-0700), sor...@fastmail.com wrote:
On Wed, Aug 2, 2023, at 12:46 PM, guo...@kernel.org wrote:
From: Guo Ren
According to qspinlock requirements, RISC-V gives out a weak LR/SC
forward progress guarantee which does not sa
On Sun, 06 Aug 2023 22:23:34 PDT (-0700), sor...@fastmail.com wrote:
On Wed, Aug 2, 2023, at 12:46 PM, guo...@kernel.org wrote:
From: Guo Ren
According to qspinlock requirements, RISC-V gives out a weak LR/SC
forward progress guarantee which does not satisfy qspinlock. But
many vendors could p
On 9/13/2023 2:55 PM, Bagas Sanjaya wrote:
On Mon, Sep 11, 2023 at 04:23:43PM +0530, Mukesh Ojha wrote:
+Qualcomm APSS Minidump kernel driver concept
+
+::
+
...
+Dump collection
+---
+
+ +---+
+ | |
+
On 9/12/2023 12:39 AM, Jeff Johnson wrote:
On 9/11/2023 4:07 AM, Krzysztof Kozlowski wrote:
On 09/09/2023 22:16, Mukesh Ojha wrote:
+/**
+ * qcom_minidump_region_register() - Register region in APSS
Minidump table.
+ * @region: minidump region.
+ *
+ * Return: On success, it returns 0 and
While some subsystems do typically have very fast turnaround times on
review this is far from standard over the kernel and is likely to set
unrealistic expectations for submitters. Tell submitters to expect 2-3
weeks instead, this will cover more of the kernel.
Signed-off-by: Mark Brown
---
Doc
On 9/13/23 08:52, Guo Ren wrote:
On Wed, Sep 13, 2023 at 4:55 PM Leonardo Bras wrote:
On Tue, Sep 12, 2023 at 09:10:08AM +0800, Guo Ren wrote:
On Mon, Sep 11, 2023 at 9:03 PM Waiman Long wrote:
On 9/10/23 23:09, Guo Ren wrote:
On Mon, Sep 11, 2023 at 10:35 AM Waiman Long wrote:
On 9/10/23
On Wed, Sep 13, 2023 at 4:55 PM Leonardo Bras wrote:
>
> On Tue, Sep 12, 2023 at 09:10:08AM +0800, Guo Ren wrote:
> > On Mon, Sep 11, 2023 at 9:03 PM Waiman Long wrote:
> > >
> > > On 9/10/23 23:09, Guo Ren wrote:
> > > > On Mon, Sep 11, 2023 at 10:35 AM Waiman Long wrote:
> > > >>
> > > >> On 9
On Wed, Sep 13, 2023 at 12:32:54PM +0530, Mukesh Ojha wrote:
> Thanks for the response.
>
> On 9/12/2023 3:48 PM, Will Deacon wrote:
> > On Mon, Sep 11, 2023 at 04:23:50PM +0530, Mukesh Ojha wrote:
> > > The reserved memory region for ramoops is assumed to be at a fixed
> > > and known location wh
On Mon, Sep 11, 2023 at 04:23:43PM +0530, Mukesh Ojha wrote:
> +Qualcomm APSS Minidump kernel driver concept
> +
> +::
> +
> ...
> +Dump collection
> +---
> +
> + +---+
> + | |
> + | | +--+
>
On Tue, Sep 12, 2023 at 09:10:08AM +0800, Guo Ren wrote:
> On Mon, Sep 11, 2023 at 9:03 PM Waiman Long wrote:
> >
> > On 9/10/23 23:09, Guo Ren wrote:
> > > On Mon, Sep 11, 2023 at 10:35 AM Waiman Long wrote:
> > >>
> > >> On 9/10/23 04:28, guo...@kernel.org wrote:
> > >>> From: Guo Ren
> > >>>
On Sun, Sep 10, 2023 at 04:28:57AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Cache-block prefetch instructions are HINTs to the hardware to
> indicate that software intends to perform a particular type of
> memory access in the near future. Enable ARCH_HAS_PREFETCHW and
> improve the ar
On Sun, Sep 10, 2023 at 04:28:56AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Move ticket-lock definition into an independent file. This is the
> preparation for the next combo spinlock of riscv.
>
> Signed-off-by: Guo Ren
> Signed-off-by: Guo Ren
> ---
> include/asm-generic/spinlock
On Wed, Sep 13, 2023 at 09:55:31AM +0800, Guo Ren wrote:
> On Tue, Sep 12, 2023 at 3:05 AM Leonardo Brás wrote:
> >
> > On Sun, 2023-09-10 at 04:28 -0400, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > The arch_spinlock_t of qspinlock has contained the atomic_t val, which
> > > satisfie
On 9/12/2023 3:24 PM, Krzysztof Kozlowski wrote:
On 12/09/2023 11:26, Mukesh Ojha wrote:
+ return -EINVAL;
+ }
+
+ mutex_init(&md->md_lock);
+ ret = qcom_apss_md_table_init(md,
&mdgtoc->subsystems[MINIDUMP_APSS_DESC]);
+ if (ret) {
+ dev_
Thanks for the response.
On 9/12/2023 3:48 PM, Will Deacon wrote:
On Mon, Sep 11, 2023 at 04:23:50PM +0530, Mukesh Ojha wrote:
The reserved memory region for ramoops is assumed to be at a fixed
and known location when read from the devicetree. This may not be
required for something like Qualcom
69 matches
Mail list logo
