Re: [Discuss] Seeking advice on net selftests netns naming method

On Tue, Nov 14, 2023 at 12:02:00PM +0100, Paolo Abeni wrote: > I personally would like sort of both :) e.g. lib function(s) to > automatically create and dispose netns, and retain a script- > specific/related name prefix.  > > The library function could optionally set the newly created namespaces

[PATCH] selftests/memfd: fix a memleak

The memory allocated within a function should be released before the function return,otherwise memleak will occur. Signed-off-by: zhujun2 --- tools/testing/selftests/memfd/fuse_test.c | 3 +++ tools/testing/selftests/memfd/memfd_test.c | 10 ++ 2 files changed, 13 insertions(+) diff -

Re: [PATCH net 0/5] mptcp: misc. fixes for v6.7

Hello: This series was applied to netdev/net.git (main) by Jakub Kicinski : On Tue, 14 Nov 2023 00:16:12 +0100 you wrote: > Here are a few fixes related to MPTCP: > > - Patch 1 limits GSO max size to ~64K when MPTCP is being used due to a > spec limit. 'gso_max_size' can exceed the max value s

RE: [PATCH v1 09/23] KVM: VMX: Switch FRED RSP0 between host and guest

> >> >diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h index > >> >f8c02bd37069..328a3447f064 100644 > >> >--- a/arch/x86/kvm/vmx/vmx.h > >> >+++ b/arch/x86/kvm/vmx/vmx.h > >> >@@ -276,6 +276,8 @@ struct vcpu_vmx { > >> > #ifdef CONFIG_X86_64 > >> > u64 msr_host_kerne

RE: [PATCH v1 13/23] KVM: VMX: Handle VMX nested exception for FRED

> >+if (idt_vectoring_info & VECTORING_INFO_DELIVER_CODE_MASK) > >+kvm_requeue_exception_e(vcpu, vector, > vmcs_read32(error_code_field), > >+idt_vectoring_info & > INTR_INFO_NESTED_EXCEPTION_MASK); > >+else > >

RE: [PATCH v1 12/23] KVM: VMX: Handle FRED event data

> >> >+ else if (is_nm_fault(intr_info) && > >> >+ vcpu->arch.guest_fpu.fpstate->xfd) > >> > >> does this necessarily mean the #NM is caused by XFD? > > > >Then the event data should be 0. Or I missed something obvious? I.e., > >it can be easily differentia

RE: [PATCH v1 14/23] KVM: VMX: Dump FRED context in dump_vmcs()

> > @@ -6440,6 +6440,8 @@ void dump_vmcs(struct kvm_vcpu *vcpu) > > > > vmentry_ctl = vmcs_read32(VM_ENTRY_CONTROLS); > > vmexit_ctl = vmcs_read32(VM_EXIT_CONTROLS); > > + secondary_vmexit_ctl = cpu_has_secondary_vmexit_ctrls() ? > > + vmcs_read64(SECONDARY_VM_EXI

RE: [PATCH v1 05/23] KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config

> > - if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) > > + if (_vmexit_control & VM_EXIT_ACTIVATE_SECONDARY_CONTROLS) { > > _secondary_vmexit_control = > > > adjust_vmx_controls64(KVM_OPTIONAL_VMX_SECONDARY_VM_EXIT_CO > NTROLS, > >

Re: selftests: gpio: crash on arm64

Tue, Nov 07, 2023 at 07:21:32PM +0530, Naresh Kamboju kirjoitti: > On Tue, 20 Jun 2023 at 22:11, Andy Shevchenko > wrote: > > On Tue, Apr 11, 2023 at 10:57:28AM +0200, Linus Walleij wrote: > > > On Mon, Apr 10, 2023 at 11:16 AM Naresh Kamboju > > > wrote: ... > > > Add a pr_info() devm_gpio_chi

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote: > diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c > index 59e15dd8d0f8..7ffe90010587 100644 > --- a/arch/x86/kernel/shstk.c > +++ b/arch/x86/kernel/shstk.c > @@ -191,18 +191,38 @@ void reset_thread_features(void) > current-

Re: [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote: > +config ARCH_HAS_USER_SHADOW_STACK > +   bool > +   help > + The architecture has hardware support for userspace shadow > call > +  stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi). I feel like normally a patch like th

Re: [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

On Tue, 2023-11-14 at 20:05 +, Mark Brown wrote: > +static void test_shadow_stack_supported(void) > +{ > +    long shadow_stack; > + > +   shadow_stack = syscall(__NR_map_shadow_stack, 0, > getpagesize(), 0); Hmm, x86 fails this call if user shadow stack is not supported in the HW or t

[PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support

Add basic test coverage for specifying the shadow stack for a newly created thread via clone3(), including coverage of the newly extended argument structure. We detect support for shadow stacks on the running system by attempting to allocate a shadow stack page during initialisation using map_shado

[PATCH RFC RFT v2 4/5] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code

The clone_args structure is extensible, with the syscall passing in the length of the structure. Inside the kernel we use copy_struct_from_user() to read the struct but this has the unfortunate side effect of silently accepting some overrun in the structure size providing the extra data is all zero

[PATCH RFC RFT v2 3/5] selftests/clone3: Factor more of main loop into test_clone3()

In order to make it easier to add more configuration for the tests and more support for runtime detection of when tests can be run pass the structure describing the tests into test_clone3() rather than picking the arguments out of it and have that function do all the per-test work. No functional c

[PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

Unlike with the normal stack there is no API for configuring the the shadow stack for a new thread, instead the kernel will dynamically allocate a new shadow stack with the same size as the normal stack. This appears to be due to the shadow stack series having been in development since before the m

[PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK

Since multiple architectures have support for shadow stacks and we need to select support for this feature in several places in the generic code provide a generic config option that the architectures can select. Suggested-by: David Hildenbrand Signed-off-by: Mark Brown --- arch/x86/Kconfig |

[PATCH RFC RFT v2 0/5] fork: Support shadow stacks in clone3()

The kernel has recently added support for shadow stacks, currently x86 only using their CET feature but both arm64 and RISC-V have equivalent features (GCS and Zisslpcfi respectively), I am actively working on GCS[1]. With shadow stacks the hardware maintains an additional stack containing only th

RE: [PATCH v1 11/23] KVM: x86: Add kvm_is_fred_enabled()

> >> FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the > >> check about long mode? > > > >It won' t allow CR4.FRED to be set if not in long mode, I don't expect it > >at runtime. Or you have one? > > I was thinking about a very contrived case: > > 1. the CPU enters 64-b

Re: [RFC PATCH v3 05/12] netdev: netdevice devmem allocator

On 11/11/23 17:19, David Ahern wrote: On 11/10/23 7:26 AM, Pavel Begunkov wrote: On 11/7/23 23:03, Mina Almasry wrote: On Tue, Nov 7, 2023 at 2:55 PM David Ahern wrote: On 11/7/23 3:10 PM, Mina Almasry wrote: On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote: On 11/5/23 7:44 PM, Mina Alma

Re: [PATCH net-next v3] selftests/net: synchronize udpgro tests' tx and rx connection

Lucas Karpinski wrote: > The sockets used by udpgso_bench_tx aren't always ready when > udpgso_bench_tx transmits packets. This issue is more prevalent in -rt > kernels, but can occur in both. Replace the hacky sleep calls with a > function that checks whether the ports in the namespace are ready f

[PATCH net-next v3] selftests/net: synchronize udpgro tests' tx and rx connection

The sockets used by udpgso_bench_tx aren't always ready when udpgso_bench_tx transmits packets. This issue is more prevalent in -rt kernels, but can occur in both. Replace the hacky sleep calls with a function that checks whether the ports in the namespace are ready for use. Suggested-by: Paolo Ab

Re: [PATCH v1 14/23] KVM: VMX: Dump FRED context in dump_vmcs()

On 8.11.23 г. 20:29 ч., Xin Li wrote: Add FRED related VMCS fields to dump_vmcs() to have it dump FRED context. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kvm/vmx/vmx.c | 48 -- 1 file changed, 41 insertions(+), 7 deletions(-) diff --

[PATCH v2 21/21] KVM: arm64: selftests: Teach get-reg-list about FPMR

FEAT_FPMR defines a new register FMPR which is available at all ELs and is discovered via ID_AA64PFR2_EL1.FPMR, add this to the set of registers that get-reg-list knows to check for with the required identification register depdendency. Signed-off-by: Mark Brown --- tools/testing/selftests/kvm/a

[PATCH v2 20/21] KVM: arm64: selftests: Document feature registers added in 2023 extensions

The 2023 architecture extensions allocated some previously usused feature registers, add comments mapping the names in get-reg-list as we do for the other allocated registers. Signed-off-by: Mark Brown --- tools/testing/selftests/kvm/aarch64/get-reg-list.c | 4 ++-- 1 file changed, 2 insertions(

[PATCH v2 16/21] arm64/hwcap: Define hwcaps for 2023 DPISA features

The 2023 architecture extensions include a large number of floating point features, most of which simply add new instructions. Add hwcaps so that userspace can enumerate these features. Signed-off-by: Mark Brown --- Documentation/arch/arm64/elf_hwcaps.rst | 49 +

[PATCH v2 19/21] kselftest/arm64: Add 2023 DPISA hwcap test coverage

Add the hwcaps added for the 2023 DPISA extensions to the hwcaps test program. Signed-off-by: Mark Brown --- tools/testing/selftests/arm64/abi/hwcap.c | 217 ++ 1 file changed, 217 insertions(+) diff --git a/tools/testing/selftests/arm64/abi/hwcap.c b/tools/testing/

[PATCH v2 18/21] kselftest/arm64: Add basic FPMR test

Verify that a FPMR frame is generated on systems that support FPMR and not generated otherwise. Signed-off-by: Mark Brown --- tools/testing/selftests/arm64/signal/.gitignore| 1 + .../arm64/signal/testcases/fpmr_siginfo.c | 82 ++ 2 files changed, 83 insertions(

[PATCH v2 17/21] kselftest/arm64: Handle FPMR context in generic signal frame parser

Teach the generic signal frame parsing code about the newly added FPMR frame, avoiding warnings every time one is generated. Signed-off-by: Mark Brown --- tools/testing/selftests/arm64/signal/testcases/testcases.c | 8 tools/testing/selftests/arm64/signal/testcases/testcases.h | 1 + 2

[PATCH v2 14/21] KVM: arm64: Add newly allocated ID registers to register descriptions

The 2023 architecture extensions have allocated some new ID registers, add them to the KVM system register descriptions so that they are visible to guests. Signed-off-by: Mark Brown --- arch/arm64/kvm/sys_regs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64

[PATCH v2 15/21] KVM: arm64: Support FEAT_FPMR for guests

FEAT_FPMR introduces a new system register FPMR which allows configuration of floating point behaviour, currently for FP8 specific features. Allow use of this in guests, disabling the trap while guests are running and saving and restoring the value along with the rest of the floating point state. S

[PATCH v2 10/21] arm64/fpsimd: Enable host kernel access to FPMR

FEAT_FPMR provides a new generally accessible architectural register FPMR. This is only accessible to EL0 and EL1 when HCRX_EL2.EnFPM is set to 1, do this when the host is running. The guest part will be done along with context switching the new register and exposing it via guest management. Signe

[PATCH v2 13/21] arm64/ptrace: Expose FPMR via ptrace

Add a new regset to expose FPMR via ptrace. It is not added to the FPSIMD registers since that structure is exposed elsewhere without any allowance for extension we don't add there. Signed-off-by: Mark Brown --- arch/arm64/kernel/ptrace.c | 42 ++ include/

[PATCH v2 12/21] arm64/signal: Add FPMR signal handling

Expose FPMR in the signal context on systems where it is supported. The kernel validates the exact size of the FPSIMD registers so we can't readily add it to fpsimd_context without disruption. Signed-off-by: Mark Brown --- arch/arm64/include/uapi/asm/sigcontext.h | 8 + arch/arm64/kernel/si

[PATCH v2 11/21] arm64/fpsimd: Support FEAT_FPMR

FEAT_FPMR defines a new EL0 accessible register FPMR use to configure the FP8 related features added to the architecture at the same time. Detect support for this register and context switch it for EL0 when present. Due to the sharing of responsibility for saving floating point state between the h

[PATCH v2 09/21] arm64/cpufeature: Hook new identification registers up to cpufeature

The 2023 architecture extensions have defined several new ID registers, hook them up to the cpufeature code so we can add feature checks and hwcaps based on their contents. Signed-off-by: Mark Brown --- arch/arm64/include/asm/cpu.h | 3 +++ arch/arm64/kernel/cpufeature.c | 28

[PATCH v2 08/21] arm64/sysreg: Add definition for FPMR

DDI0601 2023-09 defines a new sysrem register FPMR (Floating Point Mode Register) which configures the new FP8 features. Add a definition of this register. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 23 +++ 1 file changed, 23 insertions(+) diff --git a/arch/arm6

[PATCH v2 07/21] arm64/sysreg: Update HCRX_EL2 definition for DDI0601 2023-09

DDI0601 2023-09 defines new fields in HCRX_EL2 controlling access to new system registers, update our definition of HCRX_EL2 to reflect this. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/tools/sysreg b/arc

[PATCH v2 06/21] arm64/sysreg: Update SCTLR_EL1 for DDI0601 2023-09

DDI0601 2023-09 defines some new fields in SCTLR_EL1 controlling new MTE and floating point features. Update our sysreg definition to reflect these. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/tools/sys

[PATCH v2 05/21] arm64/sysreg: Update ID_AA64SMFR0_EL1 definition for DDI0601 2023-09

The 2023-09 release of DDI0601 defines a number of new feature enumeration fields in ID_AA64SMFR0_EL1. Add these fields. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 30 +++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/arch/arm64/tools/sysr

[PATCH v2 04/21] arm64/sysreg: Add definition for ID_AA64FPFR0_EL1

DDI0601 2023-09 defines a new feature register ID_AA64FPFR0_EL1 which enumerates a number of FP8 related features. Add a definition for it. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 29 + 1 file changed, 29 insertions(+) diff --git a/arch/arm64/tools/sy

[PATCH v2 02/21] arm64/sysreg: Update ID_AA64ISAR2_EL1 defintion for DDI0601 2023-09

DDI0601 2023-09 defines some new fields in previously RES0 space in ID_AA64ISAR2_EL1, together with one new enum value. Update the system register definition to reflect this. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 24 ++-- 1 file changed, 22 insertions(+), 2

[PATCH v2 03/21] arm64/sysreg: Add definition for ID_AA64ISAR3_EL1

DDI0601 2023-09 adds a new system register ID_AA64ISAR3_EL1 enumerating new floating point and TLB invalidation features. Add a defintion for it. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm64/tools/sysreg b

[PATCH v2 01/21] arm64/sysreg: Add definition for ID_AA64PFR2_EL1

DDI0601 2023-09 defines a new system register ID_AA64PFR2_EL1 which enumerates FPMR and some new MTE features. Add a definition of this register. Signed-off-by: Mark Brown --- arch/arm64/tools/sysreg | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/arm64/tools/sysr

[PATCH v2 00/21] arm64: Support for 2023 DPISA extensions

This series enables support for the data processing extensions in the newly released 2023 architecture, this is mainly support for 8 bit floating point formats. Most of the extensions only introduce new instructions and therefore only require hwcaps but there is a new EL0 visible control register

Re: [Discuss] Seeking advice on net selftests netns naming method

On Tue, 2023-11-14 at 17:55 +0800, Hangbin Liu wrote: > Good day! Following Guillaume's suggestion, I've been working on updating all > net self-tests to run in their respective netns. This modification allows us > to execute all tests in parallel, potentially saving a significant amount of > test

[Discuss] Seeking advice on net selftests netns naming method

Hi, Good day! Following Guillaume's suggestion, I've been working on updating all net self-tests to run in their respective netns. This modification allows us to execute all tests in parallel, potentially saving a significant amount of test time. However, I've encountered a challenge while making

[PATCH] selftests/media_tests: fix a resource leak

The opened file should be closed in main(), otherwise resource leak will occur that this problem was discovered by code reading Signed-off-by: zhujun2 --- tools/testing/selftests/media_tests/media_device_open.c | 3 +++ tools/testing/selftests/media_tests/media_device_test.c | 3 +++ 2 files cha

Re: [PATCH v1 12/23] KVM: VMX: Handle FRED event data

On Tue, Nov 14, 2023 at 12:34:02PM +0800, Li, Xin3 wrote: >> >+ else if (is_nm_fault(intr_info) && >> >+vcpu->arch.guest_fpu.fpstate->xfd) >> >> does this necessarily mean the #NM is caused by XFD? > >Then the event data should be 0. Or I missed somet

Re: [PATCH v1 11/23] KVM: x86: Add kvm_is_fred_enabled()

On Tue, Nov 14, 2023 at 12:42:13PM +0800, Li, Xin3 wrote: >> >+ return cpu_feature_enabled(X86_FEATURE_FRED) && >> >+ kvm_is_cr4_bit_set(vcpu, X86_CR4_FRED); >> >> FRED is enabled when CR4.FRED = IA32_EFER.LMA = 1. Any reason to omit the >> check about long mode? > >It won' t allow CR4.