On Thu, Sep 14, 2023 at 12:49:45PM +0800, Guo Ren wrote:
> 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, gu
On Tue, Sep 12, 2023 at 09:08:34AM +0800, Guo Ren wrote:
> On Mon, Sep 11, 2023 at 11:34 PM Waiman Long wrote:
> >
> > On 9/10/23 04:29, guo...@kernel.org wrote:
> > > From: Guo Ren
> > >
> > > Allow cmdline to force the kernel to use queued_spinlock when
> > > CONFIG_RISCV_COMBO_SPINLOCKS=y.
> >
On Sun, Sep 10, 2023 at 04:29:02AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Add a static key controlling whether virt_spin_lock() should be
> called or not. When running on bare metal set the new key to
> false.
>
> The KVM guests fall back to a Test-and-Set spinlock, because fair
> l
On Sun, Sep 10, 2023 at 04:29:03AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> The early version of T-Head C9xx cores has a store merge buffer
> delay problem. The store merge buffer could improve the store queue
> performance by merging multi-store requests, but when there are not
> cont
On Sun, Sep 10, 2023 at 04:29:04AM -0400, 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 produce stronger forward guarantee LR/SC to
> ensure th
On Thu, Sep 14, 2023 at 12:46:56PM +0800, Guo Ren wrote:
> 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:
> > > a8ad07e524
This patch sets up a new feature to the Linux kernel to have the ability,
while module signature checking is enabled, to delay the moment where
these signatures are effectively checked. The feature is structure into
two main key points, the feature can be enabled by a new command line
kernel argume
This commit introduces a novel boot argument parameter that provides an
advanced level of control over the verification of module signatures
during the initial stages of booting. With this enhancement, we gain the
capability to postpone the verification of module signatures to after
intrd stage is
Update kernel-parameters.txt to reflect new deferred signature
verification.
Enhances boot speed by allowing unsigned modules in initrd after
bootloader check.
Signed-off-by: Alessandro Carminati (Red Hat)
---
Documentation/admin-guide/kernel-parameters.txt | 9 +
1 file changed, 9 inser
On 14/09/2023 7:02 am, Juergen Gross wrote:
> 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
>
On 14/09/2023 7:09 am, Jan Beulich wrote:
> 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
The author referred to the ftrace log, but mentioned console log
instead. Fix the typo.
Signed-off-by: Tudor Ambarus
---
Documentation/admin-guide/pstore-blk.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/pstore-blk.rst
b/Documentation/admin-gu
Reword the sentence to "care about the {oops/panic, pmsg, console} log."
Signed-off-by: Tudor Ambarus
---
Documentation/admin-guide/pstore-blk.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/pstore-blk.rst
b/Documentation/admin-guide/pst
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 14/09/2023 5:47 am, 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
> ---
> arch/x86/include/asm/msr.h | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/
On 14/09/2023 5:47 am, Xin Li wrote:
> 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 .
>
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 Thu, Sep 14, 2023 at 04:25:53PM +0200, Andrew Jones wrote:
> 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
On 9/14/23 03:32, Leonardo Bras wrote:
On Tue, Sep 12, 2023 at 09:08:34AM +0800, Guo Ren wrote:
On Mon, Sep 11, 2023 at 11:34 PM Waiman Long wrote:
On 9/10/23 04:29, guo...@kernel.org wrote:
From: Guo Ren
Allow cmdline to force the kernel to use queued_spinlock when
CONFIG_RISCV_COMBO_SPINL
Andrew!
On Thu, Sep 14 2023 at 15:05, andrew wrote:
> On 14/09/2023 5:47 am, Xin Li wrote:
>> +static __always_inline void wrmsrns(u32 msr, u64 val)
>> +{
>> +__wrmsrns(msr, val, val >> 32);
>> +}
>
> This API works in terms of this series where every WRMSRNS is hidden
> behind a FRED check, b
On September 14, 2023 4:00:39 PM PDT, Thomas Gleixner
wrote:
>Andrew!
>
>On Thu, Sep 14 2023 at 15:05, andrew wrote:
>> On 14/09/2023 5:47 am, Xin Li wrote:
>>> +static __always_inline void wrmsrns(u32 msr, u64 val)
>>> +{
>>> + __wrmsrns(msr, val, val >> 32);
>>> +}
>>
>> This API works in ter
On 15/09/2023 12:00 am, Thomas Gleixner wrote:
>> and despite what Juergen said, I'm going to recommend that you do wire
>> this through the paravirt infrastructure, for the benefit of regular
>> users having a nice API, not because XenPV is expecting to do something
>> wildly different here.
> I f
On Fri, Sep 15 2023 at 00:46, andrew wrote:
> On 15/09/2023 12:00 am, Thomas Gleixner wrote:
>> So no. I'm fundamentally disagreeing with your recommendation. The way
>> forward is:
>>
>> 1) Provide the native variant for wrmsrns(), i.e. rename the proposed
>> wrmsrns() to native_wrmsr_ns()
On 15/09/2023 1:12 am, Thomas Gleixner wrote:
> On Fri, Sep 15 2023 at 00:46, andrew wrote:
>> On 15/09/2023 12:00 am, Thomas Gleixner wrote:
>>> So no. I'm fundamentally disagreeing with your recommendation. The way
>>> forward is:
>>>
>>> 1) Provide the native variant for wrmsrns(), i.e. rename
On 9/14/23 17:33, andrew.coop...@citrix.com wrote:
It's an assumption about what "definitely won't" be paravirt in the future.
XenPV stack handling is almost-FRED-like and has been for the better
part of two decades.
You frequently complain that there's too much black magic holding XenPV
toget
On Fri, Sep 15 2023 at 00:46, andrew wrote:
> On 15/09/2023 12:00 am, Thomas Gleixner wrote:
> What I meant was "there should be the two top-level APIs, and under the
> covers they DTRT". Part of doing the right thing is to wire up paravirt
> for configs where that is specified.
>
> Anything else
WRMSR has one complexity that most other PV-ops don't, and that's the
exception table reference for the instruction itself.
In a theoretical future ought to look like:
mov$msr, %ecx
mov$lo, %eax
mov$hi, %edx
1: {call paravirt_blah(%rip) | cs...cs wrmsr | cs...cs wrmsr
On Thu, Sep 14 2023 at 14:15, andrew wrote:
> PV guests are never going to see FRED (or LKGS for that matter) because
> it advertises too much stuff which simply traps because the kernel is in
> CPL3.
>
> That said, the 64bit PV ABI is a whole lot closer to FRED than it is to
> IDT delivery. (Almo
On 15/09/2023 2:01 am, H. Peter Anvin wrote:
> The whole bit with alternatives and pvops being separate is a major
> maintainability problem, and honestly it never made any sense in the
> first place. Never have two mechanisms to do one job; it makes it
> harder to grok their interactions.
This bi
On 15/09/2023 1:38 am, H. Peter Anvin wrote:
> On 9/14/23 17:33, andrew.coop...@citrix.com wrote:
>>
>> It's an assumption about what "definitely won't" be paravirt in the
>> future.
>>
>> XenPV stack handling is almost-FRED-like and has been for the better
>> part of two decades.
>>
>> You frequen
On 9/14/23 18:46, andrew.coop...@citrix.com wrote:
On 15/09/2023 1:38 am, H. Peter Anvin wrote:
On 9/14/23 17:33, andrew.coop...@citrix.com wrote:
It's an assumption about what "definitely won't" be paravirt in the
future.
XenPV stack handling is almost-FRED-like and has been for the better
p
On Thu, Sep 14, 2023 at 5:43 PM Leonardo Bras wrote:
>
> On Thu, Sep 14, 2023 at 12:46:56PM +0800, Guo Ren wrote:
> > 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 requ
On Thu, 14 Sep 2023 13:37:28 +, Tudor Ambarus wrote:
> Reword the sentence to "care about the {oops/panic, pmsg, console} log."
>
>
Applied to for-next/pstore, thanks!
[1/2] docs: pstore-blk.rst: use "about" as a preposition after "care"
https://git.kernel.org/kees/c/a321a540e3c9
[2/2
On 15.09.23 03:07, Thomas Gleixner wrote:
On Thu, Sep 14 2023 at 14:15, andrew wrote:
PV guests are never going to see FRED (or LKGS for that matter) because
it advertises too much stuff which simply traps because the kernel is in
CPL3.
That said, the 64bit PV ABI is a whole lot closer to FRED
On 15.09.23 03:16, andrew.coop...@citrix.com wrote:
On 15/09/2023 2:01 am, H. Peter Anvin wrote:
The whole bit with alternatives and pvops being separate is a major
maintainability problem, and honestly it never made any sense in the
first place. Never have two mechanisms to do one job; it makes
On Sun, Sep 10, 2023 at 04:29:05AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Using static_call to switch between:
> native_queued_spin_lock_slowpath()__pv_queued_spin_lock_slowpath()
> native_queued_spin_unlock() __pv_queued_spin_unlock()
>
> Finish the pv_wait implem
On Wed, 13 Sep 2023 21:47:29 -0700
Xin Li wrote:
> 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
This looks good to me.
Acked-by: Masami Hirama
On Sun, Sep 10, 2023 at 04:29:06AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Disables the qspinlock slow path using PV optimizations which
> allow the hypervisor to 'idle' the guest on lock contention.
>
> Signed-off-by: Guo Ren
> Signed-off-by: Guo Ren
> ---
> Documentation/admin-g
On Sun, Sep 10, 2023 at 04:29:07AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Implement pv_kick with SBI implementation, and add SBI_EXT_PVLOCK
> extension detection.
>
> Signed-off-by: Guo Ren
> Signed-off-by: Guo Ren
> ---
> arch/riscv/include/asm/sbi.h | 6 ++
> arch
On Sun, Sep 10, 2023 at 04:29:08AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Add kconfig entry for paravirt_spinlock, an unfair qspinlock
> virtualization-friendly backend, by halting the virtual CPU rather
> than spinning.
>
> Signed-off-by: Guo Ren
> Signed-off-by: Guo Ren
> ---
>
On Sun, Sep 10, 2023 at 04:29:09AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Add trace point for pv_kick/wait, here is the output:
>
> entries-in-buffer/entries-written: 33927/33927 #P:12
>
> _-=> irqs-off/BH-disabled
>
On Sun, Sep 10, 2023 at 04:29:10AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> Add the files functions needed to support the SBI PVLOCK (paravirt
> qspinlock kick_cpu) extension. This is a preparation for the next
> core implementation of kick_cpu.
>
> Signed-off-by: Guo Ren
> Signed-of
On Sun, Sep 10, 2023 at 04:29:11AM -0400, guo...@kernel.org wrote:
> From: Guo Ren
>
> We only need to call the kvm_vcpu_kick() and bring target_vcpu
> from the halt state. No irq raised, no other request, just a pure
> vcpu_kick.
>
> Signed-off-by: Guo Ren
> Signed-off-by: Guo Ren
> ---
> ar
43 matches
Mail list logo
