On 18-04-24, 20:31, Muhammad Usama Anjum wrote:
> This test outputs lots of information. Let's conform the core part of
> the test to TAP and leave the information printing messages for now.
> Include ktap_helpers.sh to print conformed logs. Use KSFT_* macros to
> return the correct exit code for t
On Fri, Apr 19, 2024 at 08:15:25AM +0200, Markus Elfring wrote:
> > If the device register fails, free the allocated memory before
> > returning.
>
> Can a description variant (like the following) be more appropriate?
>
>Free the allocated memory (after a device registration failure)
>bef
On Tue, Apr 16, 2024 at 04:08:30PM +0200, Benjamin Tissoires wrote:
> again, copy/paste from bpf_timer_start().
>
> Signed-off-by: Benjamin Tissoires
> ---
> kernel/bpf/helpers.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/kernel/bpf/helpers.c b/kernel/bpf
> If the device register fails, free the allocated memory before
> returning.
Can a description variant (like the following) be more appropriate?
Free the allocated memory (after a device registration failure)
before returning.
Thus add a jump target so that a bit of exception handling c
Hi Andy,
On Fri, Apr 12, 2024 at 2:50 PM Andy Chiu wrote:
>
> Currently we only support Vector for SMP platforms, that is, all SMP
> cores have the same vlenb. If we happen to detect a mismatching vlen, it
> is better to just fail bootting it up to prevent further race/scheduling
> issues.
>
> Al
On Fri, Apr 19, 2024 at 07:40:43AM +0200, Markus Elfring wrote:
> > kunit_init_device() should unregister the device on bus register error,
> > but mistakenly it tries to unregister the bus.
>
> Would the following description variant be more appropriate?
>
>kunit_init_device() should unregis
On Tue, Apr 16, 2024 at 04:08:22PM +0200, Benjamin Tissoires wrote:
> WRITE_ONCE(*(u64 *)field_ptr, 0);
> @@ -1119,6 +1127,8 @@ static int map_check_btf(struct bpf_map *map, struct
> bpf_token *token,
> }
> break;
>
On Tue, Apr 16, 2024 at 04:08:19PM +0200, Benjamin Tissoires wrote:
> Mostly a copy/paste from the bpf_timer API, without the initialization
> and free, as they will be done in a separate patch.
>
> Signed-off-by: Benjamin Tissoires
Patches 2-6 look good.
On Tue, Apr 16, 2024 at 04:08:21PM +0200, Benjamin Tissoires wrote:
> Introduce support for KF_ARG_PTR_TO_WORKQUEUE. The kfuncs will use bpf_wq
> as argument and that will be recognized as workqueue argument by verifier.
> bpf_wq_kern casting can happen inside kfunc, but using bpf_wq in
> argument
> kunit_init_device() should unregister the device on bus register error,
> but mistakenly it tries to unregister the bus.
Would the following description variant be more appropriate?
kunit_init_device() should unregister the device on bus registration error.
But it mistakenly tries to unre
On Tue, Apr 16, 2024 at 04:08:24PM +0200, Benjamin Tissoires wrote:
> We need to teach the verifier about the second argument which is declared
> as void * but which is of type KF_ARG_PTR_TO_MAP. We could have dropped
> this extra case if we declared the second argument as struct bpf_map *,
> but t
On Fri, 19 Apr 2024 at 05:02, Wander Lairson Costa wrote:
>
> If the device register fails, free the allocated memory before
> returning.
>
> Signed-off-by: Wander Lairson Costa
> Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
> ---
Thanks.
I'm not sure this is correct, though...
On Fri, 19 Apr 2024 at 05:02, Wander Lairson Costa wrote:
>
> kunit_init_device() should unregister the device on bus register error,
> but mistakenly it tries to unregister the bus.
>
> Unregister the device instead of the bus.
>
> Signed-off-by: Wander Lairson Costa
> Fixes: d03c720e03bd ("kuni
From: Jeff Xu
fix compile warning reported by test robot [1]
Please apply on top of patch titled:
"selftest mm/mseal: style change"
(which already in mm-unstable)
[1] https://lore.kernel.org/all/202404190226.ofjoewv8-...@intel.com/
Thanks!
-Jeff
Jeff Xu (1):
selftest mm/mseal: fix compile
From: Jeff Xu
fix compile warning reported by test robot
Signed-off-by: Jeff Xu
Reported-by: kernel test robot
Closes: https://lore.kernel.org/r/202404190226.ofjoewv8-...@intel.com/
---
tools/testing/selftests/mm/mseal_test.c | 3 +--
tools/testing/selftests/mm/seal_elf.c | 3 +--
2 files c
On Thu, Apr 18, 2024 at 1:19 PM Suren Baghdasaryan wrote:
>
> On Tue, Apr 16, 2024 at 12:40 PM Jeff Xu wrote:
> >
> > On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett
> > wrote:
> > >
> > > * jef...@chromium.org [240415 12:35]:
> > > > From: Jeff Xu
> > > >
> > > > This is V10 version, it reba
Wrap typical checks like whether given command used by the test
is available in helpers.
Signed-off-by: Jakub Kicinski
---
.../selftests/drivers/net/lib/py/env.py | 29 ++-
tools/testing/selftests/drivers/net/ping.py | 6
2 files changed, 34 insertions(+), 1 deletio
More complex tests often have to spawn a background process,
like a server which will respond to requests or tcpdump.
Add support for creating such processes using the with keyword:
with bkg("my-daemon", ..):
# my-daemon is alive in this block
My initial thought was to add this support to
While writing tests with a lot more cases I got tired of having
to jump back and forth to add the name of the test to the ksft_run()
list. Most unittest frameworks do some name matching, e.g. assume
that functions with names starting with test_ are test cases.
Support similar flow in ksft_run(). L
Add a very simple test for testing with a remote system.
Both IPv4 and IPv6 connectivity is optional, later change
will add checks to skip tests based on available addresses.
Using netdevsim:
$ ./run_kselftest.sh -t drivers/net:ping.py
TAP version 13
1..1
# timeout set to 45
# selftests: dri
Nothing surprising here, hopefully. Wrap the variables from
the environment into a class or spawn a netdevsim based env
and pass it to the tests.
Signed-off-by: Jakub Kicinski
---
.../testing/selftests/drivers/net/README.rst | 33 +++
.../selftests/drivers/net/lib/py/env.py | 98 +
The tests with a remote end will use a different class,
for clarity, but will also need to parse the env.
So factor parsing the env out to a function.
Signed-off-by: Jakub Kicinski
---
.../selftests/drivers/net/lib/py/env.py | 43 +++
1 file changed, 26 insertions(+), 17 de
Define the remote endpoint "model". To execute most meaningful device
driver tests we need to be able to communicate with a remote system,
and have it send traffic to the device under test.
Various test environments will have different requirements.
0) "Local" netdevsim-based testing can simply u
Hi!
Implement support for tests which require access to a remote system /
endpoint which can generate traffic.
This series concludes the "groundwork" for upstream driver tests.
I wanted to support the three models which came up in discussions:
- SW testing with netdevsim
- "local" testing with
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Wed, 17 Apr 2024 16:11:38 -0700 you wrote:
> Hi!
>
> Implement support for tests which require access to a remote system /
> endpoint which can generate traffic.
> This series concludes the "groundwork" for upstr
If the device register fails, free the allocated memory before
returning.
Signed-off-by: Wander Lairson Costa
Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
---
lib/kunit/device.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/kunit/device.c b/l
kunit_init_device() should unregister the device on bus register error,
but mistakenly it tries to unregister the bus.
Unregister the device instead of the bus.
Signed-off-by: Wander Lairson Costa
Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
---
lib/kunit/device.c | 2 +-
1 file
Hi,
These two patches fix some minor error path mistakes in the device
module.
Changes
---
v1->v2
* Add fixes tag
* Add imperative statement in the commit description
v2->v3
* Add a goto exit label kunit_device_register_internal
Wander Lairson Costa (2):
kunit: unregister the device on er
On Tue, Apr 16, 2024 at 12:40 PM Jeff Xu wrote:
>
> On Tue, Apr 16, 2024 at 8:13 AM Liam R. Howlett
> wrote:
> >
> > * jef...@chromium.org [240415 12:35]:
> > > From: Jeff Xu
> > >
> > > This is V10 version, it rebases v9 patch to 6.9.rc3.
> > > We also applied and tested mseal() in chrome and
Hi Atish,
On 2024-04-18 2:47 AM, Atish Patra wrote:
>
> On 4/16/24 21:02, Samuel Holland wrote:
>> Hi Atish,
>>
>> On 2024-04-16 1:44 PM, Atish Patra wrote:
>>> SBI v2.0 SBI introduced PMU snapshot feature which adds the following
>>> features.
>>>
>>> 1. Read counter values directly from the sha
On Thu, Apr 18, 2024 at 11:41:29AM -0700, Eric Biggers wrote:
> If the RISC-V kernel ever disables V, then it should also disable everything
> that depends on V.
>
> This would be similar to how on x86, if the kernel decides to disable AVX to
> mitigate the Gather Data Sampling vulnerability, it
On Thu, 18 Apr 2024 10:44:39 -0400 Willem de Bruijn wrote:
> > +def test_tcp(cfg) -> None:
> > +port = random.randrange(1024 + (1 << 15))
> > +with bkg(f"nc -l {cfg.addr} {port}") as nc:
> > +wait_port_listen(port)
> > +
> > +cmd(f"echo ping | nc {cfg.addr} {port}",
> > +
From: Jack Allister
In the common case (where kvm->arch.use_master_clock is true), the KVM
clock is defined as a simple arithmetic function of the guest TSC, based on
a reference point stored in kvm->arch.master_kernel_ns and
kvm->arch.master_cycle_now.
The existing KVM_[GS]ET_CLOCK functionalit
From: David Woodhouse
When in 'master clock mode' (i.e. when host and guest TSCs are behaving
sanely and in sync), the KVM clock is defined in terms of the guest TSC.
When TSC scaling is used, calculating the KVM clock directly from *host*
TSC cycles leads to a systemic drift from the values cal
From: David Woodhouse
This was introduced in commit 0061d53daf26 ("KVM: x86: limit difference
between kvmclock updates") to reduce cross-vCPU differences which arose
because the KVM clock was based on CLOCK_MONOTONIC and thus subject to
NTP frequency corrections.
However, commit 53fafdbb8b21 ("K
From: David Woodhouse
This effectively reverts commit 332967a3eac0 ("x86: kvm: introduce
periodic global clock updates"). The periodic update was introduced to
propagate NTP corrections to the guest KVM clock, when the KVM clock was
based on CLOCK_MONOTONIC.
However, commit 53fafdbb8b21 ("KVM: x
From: David Woodhouse
KVM does make an attempt to cope with non-constant TSC, and has notifiers
to handle host TSC frequency changes. However, it *only* adjusts the KVM
clock, and doesn't adjust TSC frequency scaling when the host changes.
This is presumably because non-constant TSCs were fixed
From: David Woodhouse
The KVM clock is an interesting thing. It is defined as "nanoseconds
since the guest was created", but in practice it runs at two *different*
rates — or three different rates, if you count implementation bugs.
Definition A is that it runs synchronously with the CLOCK_MONOTO
I lied, there aren't three different definitions of the KVM clock. The
fourth is on i386, where it's still based on CLOCK_MONOTONIC (well,
boot time which might as well be the same sine we offset it anyway).
If we fix *that* to be based on CLOCK_MONOTONIC_RAW then we can rip out
a whole bunch of m
From: David Woodhouse
The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully
inadequate. It ignores TSC scaling, and ignores the fact that the host
TSC may differ from one host to the next (and in fact because of the way
the kernel calibrates it, it generally differs from one bo
From: David Woodhouse
The kvm_guest_time_update() function scales the host TSC frequency to
the guest's using kvm_scale_tsc() and the v->arch.l1_tsc_scaling_ratio
scaling ratio previously calculated for that vCPU. Then calcuates the
scaling factors for the KVM clock itself based on that guest TSC
From: Jack Allister
A VM's KVM/PV clock has an inherent relationship to its TSC (guest). When
either the host system live-updates or the VM is live-migrated this pairing
of the two clock sources should stay the same.
In reality this is not the case without some correction taking place. Two
new I
From: David Woodhouse
Commit 53fafdbb8b21 ("KVM: x86: switch KVMCLOCK base to monotonic raw
clock") did so only for 64-bit hosts, by capturing the boot offset from
within the existing clocksource notifier update_pvclock_gtod().
That notifier was added in commit 16e8d74d2da9 ("KVM: x86: notifier
Jakub Kicinski wrote:
> On Thu, 18 Apr 2024 10:26:19 -0400 Willem de Bruijn wrote:
> > > -def ksft_run(cases, args=()):
> > > +def ksft_run(cases=None, globs=None, case_pfx=None, args=()):
> > > +cases = cases or []
> > > +
> > > +if globs and case_pfx:
> > > +for key, value in glob
On Thu, 18 Apr 2024 10:26:19 -0400 Willem de Bruijn wrote:
> > -def ksft_run(cases, args=()):
> > +def ksft_run(cases=None, globs=None, case_pfx=None, args=()):
> > +cases = cases or []
> > +
> > +if globs and case_pfx:
> > +for key, value in globs.items():
> > +stats_wi
On Thu, Apr 18, 2024 at 07:26:00PM +0100, Conor Dooley wrote:
> That's great if it does require that the version of the vector extension
> must be standard. Higher quality spec than most if it does. But
> "supported" in the context of riscv_isa_extension_available() means that
> the hardware suppor
On Thu, Apr 18, 2024 at 07:26:00PM +0100, Conor Dooley wrote:
> On Thu, Apr 18, 2024 at 10:39:46AM -0700, Eric Biggers wrote:
> > On Thu, Apr 18, 2024 at 10:32:03AM -0700, Eric Biggers wrote:
> > > On Thu, Apr 18, 2024 at 05:53:55PM +0100, Conor Dooley wrote:
> > > > > If it would be useful to do s
On Thu, Apr 18, 2024 at 10:39:46AM -0700, Eric Biggers wrote:
> On Thu, Apr 18, 2024 at 10:32:03AM -0700, Eric Biggers wrote:
> > On Thu, Apr 18, 2024 at 05:53:55PM +0100, Conor Dooley wrote:
> > > > If it would be useful to do so, we should be able to enable some of the
> > > > code
> > > > with
>> Common error handling code can be used instead
>> if an additional label would be applied for a corresponding jump target.
>>
>> How do you think about to increase the application of scope-based resource
>> management here?
>
> I thought about that. But I think the code is simple enough (for no
On Thu, Apr 18, 2024 at 10:32:03AM -0700, Eric Biggers wrote:
> On Thu, Apr 18, 2024 at 05:53:55PM +0100, Conor Dooley wrote:
> > > If it would be useful to do so, we should be able to enable some of the
> > > code
> > > with a smaller VLEN and/or EEW once it has been tested in those
> > > config
On Thu, Apr 18, 2024 at 05:53:55PM +0100, Conor Dooley wrote:
> > If it would be useful to do so, we should be able to enable some of the code
> > with a smaller VLEN and/or EEW once it has been tested in those
> > configurations.
> > Some of it should work, but some of it won't be able to work.
On 4/18/24 5:52 PM, Joey Gouly wrote:> Hi again,
>
> On Thu, Mar 14, 2024 at 02:40:45PM +0500, Muhammad Usama Anjum wrote:
>> The atexit() is called from parent process as well as forked processes.
>> Hence the child restores the settings at exit while the parent is still
>> executing. Fix this by
On Thu, Apr 18, 2024 at 12:24 PM Markus Elfring wrote:
>
> > If the device register fails, free the allocated memory before
> > returning.
>
> * I suggest to use the word “registration” (instead of “register”)
> in the commit message.
>
> * Would you like to add the tag “Fixes” accordingly?
>
>
On 4/18/2024 2:37 AM, Naresh Kamboju wrote:
> The Linux next building selftests with gcc-13 found these build warnings
> and errors.
>
> Reported-by: Linux Kernel Functional Testing
>
> Build log:
> -
> Path:
> selftests/resctrl/resctrl_tests/
>
> In file included from resctrl.h:24,
On Thu, Apr 18, 2024 at 08:52:56AM -0700, Eric Biggers wrote:
> Hi Conor,
>
> On Thu, Apr 18, 2024 at 12:02:10PM +0100, Conor Dooley wrote:
> > +CC Eric, Jerry
> >
> > On Fri, Apr 12, 2024 at 02:49:03PM +0800, Andy Chiu wrote:
> > > Make has_vector take one argument. This argument represents the
> The test_sock_addr.{c,sh} can be retired as long as all its tests are migrated
> to sock_addr.c
test_sock_addr.c has a few more test dimensions than
prog_tests/sock_addr.c currently does, so it covers a few more
scenarios.
struct sock_addr_test {
const char *descr;
/* BPF prog propertie
On Thu, 18 Apr 2024 13:00:36 -0300, Wander Lairson Costa wrote:
> Hi,
>
> These two patches fix some minor error path mistakes in the device
> module.
>
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
If the device register fails, free the allocated memory before
returning.
Signed-off-by: Wander Lairson Costa
Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
---
lib/kunit/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kunit/device.c b/lib/kunit/device.c
index 25c8
kunit_init_device() should unregister the device on bus register error,
but mistakenly it tries to unregister the bus.
Unregister the device instead of the bus.
Signed-off-by: Wander Lairson Costa
Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
---
lib/kunit/device.c | 2 +-
1 file
Hi,
These two patches fix some minor error path mistakes in the device
module.
Changes:
v1->v2:
* Add fixes tag.
* Add an imperative statement in the first commit descripton.
Wander Lairson Costa (2):
kunit: unregister the device on error
kunit: avoid memory leak on device register
Hi Conor,
On Thu, Apr 18, 2024 at 12:02:10PM +0100, Conor Dooley wrote:
> +CC Eric, Jerry
>
> On Fri, Apr 12, 2024 at 02:49:03PM +0800, Andy Chiu wrote:
> > Make has_vector take one argument. This argument represents the minimum
> > Vector subextension that the following Vector actions assume.
>
This test outputs lots of information. Let's conform the core part of
the test to TAP and leave the information printing messages for now.
Include ktap_helpers.sh to print conformed logs. Use KSFT_* macros to
return the correct exit code for the kselftest framework and CIs to
understand the exit st
> If the device register fails, free the allocated memory before
> returning.
* I suggest to use the word “registration” (instead of “register”)
in the commit message.
* Would you like to add the tag “Fixes” accordingly?
> +++ b/lib/kunit/device.c
> @@ -131,6 +131,7 @@ static struct kunit_dev
On Thu, Apr 18, 2024 at 12:06 PM Markus Elfring wrote:
>
> > kunit_init_device() should unregister the device on bus register error.
>
> * Would another imperative wording be desirable also for this change
> description?
It makes sense, I will change the comment description.
>
> * Will the ta
Paolo Abeni wrote:
> On Fri, 2024-04-12 at 17:55 +0200, Richard Gobert wrote:
>> This patch adds network_offset and inner_network_offset to napi_gro_cb, and
>> makes sure both are set correctly. In the common path there's only one
>> write (skb_gro_reset_offset).
>>
>> Signed-off-by: Richard Gobert
Paolo Abeni wrote:
> On Tue, 2024-04-16 at 11:21 +0200, Paolo Abeni wrote:
>> On Fri, 2024-04-12 at 17:55 +0200, Richard Gobert wrote:
>>> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
>>> iph->id, ...) against all packets in a loop. These flush checks are used
>>> currentl
> kunit_init_device() should unregister the device on bus register error.
* Would another imperative wording be desirable also for this change
description?
* Will the tag “Fixes” become relevant here?
Regards,
Markus
Jakub Kicinski wrote:
> More complex tests often have to spawn a background process,
> like a server which will respond to requests or tcpdump.
>
> Add support for creating such processes using the with keyword:
>
> with bkg("my-daemon", ..):
> # my-daemon is alive in this block
>
> My in
Jakub Kicinski wrote:
> While writing tests with a lot more cases I got tired of having
> to jump back and forth to add the name of the test to the ksft_run()
> list. Most unittest frameworks do some name matching, e.g. assume
> that functions with names starting with test_ are test cases.
>
> Sup
Hi Palmer,
On Thu, Apr 18, 2024 at 6:13 PM Clément Léger wrote:
>
> Add support for (yet again) more RVA23U64 missing extensions. Add
> support for Zcmop, Zca, Zcf, Zcd and Zcb extensions isa string parsing,
> hwprobe and kvm support. Zce, Zcmt and Zcmp extensions have been left
> out since they
On Thu, Apr 18, 2024 at 6:14 PM Clément Léger wrote:
>
> The KVM RISC-V allows Zcmop extension for Guest/VM so add this
> extension to get-reg-list test.
>
> Signed-off-by: Clément Léger
LGTM.
Reviewed-by: Anup Patel
Acked-by: Anup Patel
Thanks,
Anup
> ---
> tools/testing/selftests/kvm/ris
On Thu, Apr 18, 2024 at 6:14 PM Clément Léger wrote:
>
> Extend the KVM ISA extension ONE_REG interface to allow KVM user space
> to detect and enable Zcmop extension for Guest/VM.
>
> Signed-off-by: Clément Léger
LGTM.
Reviewed-by: Anup Patel
Acked-by: Anup Patel
Thanks,
Anup
> ---
> arch
On Thu, Apr 18, 2024 at 6:14 PM Clément Léger wrote:
>
> The KVM RISC-V allows Zca, Zcf, Zcd and Zcb extensions for Guest/VM so
> add these extensions to get-reg-list test.
>
> Signed-off-by: Clément Léger
LGTM.
Reviewed-by: Anup Patel
Acked-by: Anup Patel
Thanks,
Anup
> ---
> tools/testin
On Thu, Apr 18, 2024 at 6:14 PM Clément Léger wrote:
>
> Extend the KVM ISA extension ONE_REG interface to allow KVM user space
> to detect and enable Zca, Zcf, Zcd and Zcb extensions for Guest/VM.
>
> Signed-off-by: Clément Léger
LGTM.
Reviewed-by: Anup Patel
Acked-by: Anup Patel
Thanks,
An
If the device register fails, free the allocated memory before
returning.
Signed-off-by: Wander Lairson Costa
---
lib/kunit/device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kunit/device.c b/lib/kunit/device.c
index 25c81ed465fb..d8c09dcb3e79 100644
--- a/lib/kunit/device.c
+++ b/
kunit_init_device() should unregister the device on bus register error.
Signed-off-by: Wander Lairson Costa
---
lib/kunit/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/kunit/device.c b/lib/kunit/device.c
index abc603730b8e..25c81ed465fb 100644
--- a/lib/kunit/d
Hi,
These two patches fix some minor error path mistakes in the device
module.
Wander Lairson Costa (2):
kunit: unregister the device on error
kunit: avoid memory leak on device register error
lib/kunit/device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.44.0
Hi again,
On Thu, Mar 14, 2024 at 02:40:45PM +0500, Muhammad Usama Anjum wrote:
> The atexit() is called from parent process as well as forked processes.
> Hence the child restores the settings at exit while the parent is still
> executing. Fix this by checking pid of atexit() calling process and
The KVM RISC-V allows Zcmop extension for Guest/VM so add this
extension to get-reg-list test.
Signed-off-by: Clément Léger
---
tools/testing/selftests/kvm/riscv/get-reg-list.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/kvm/riscv/get-reg-list.c
b/tools/testi
Extend the KVM ISA extension ONE_REG interface to allow KVM user space
to detect and enable Zcmop extension for Guest/VM.
Signed-off-by: Clément Léger
---
arch/riscv/include/uapi/asm/kvm.h | 1 +
arch/riscv/kvm/vcpu_onereg.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/riscv/
Export Zcmop ISA extension through hwprobe.
Signed-off-by: Clément Léger
---
Documentation/arch/riscv/hwprobe.rst | 4
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/sys_hwprobe.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.r
Add parsing for Zcmop ISA extension which was ratified in commit
b854a709c00 ("Zcmop is ratified/1.0") of the riscv-isa-manual.
Signed-off-by: Clément Léger
---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/i
Add description for the Zcmop (Compressed May-Be-Operations) ISA
extension which was ratified in commit c732a4f39a4 ("Zcmop is
ratified/1.0") of the riscv-isa-manual.
Signed-off-by: Clément Léger
---
.../devicetree/bindings/riscv/extensions.yaml| 12
1 file changed, 12 inser
The KVM RISC-V allows Zca, Zcf, Zcd and Zcb extensions for Guest/VM so
add these extensions to get-reg-list test.
Signed-off-by: Clément Léger
---
tools/testing/selftests/kvm/riscv/get-reg-list.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/testing/selftests/kvm/ri
Extend the KVM ISA extension ONE_REG interface to allow KVM user space
to detect and enable Zca, Zcf, Zcd and Zcb extensions for Guest/VM.
Signed-off-by: Clément Léger
---
arch/riscv/include/uapi/asm/kvm.h | 4
arch/riscv/kvm/vcpu_onereg.c | 8
2 files changed, 12 insertions(+
Export Zca, Zcf, Zcd and Zcb ISA extension through hwprobe.
Signed-off-by: Clément Léger
---
Documentation/arch/riscv/hwprobe.rst | 20
arch/riscv/include/uapi/asm/hwprobe.h | 4
arch/riscv/kernel/sys_hwprobe.c | 4
3 files changed, 28 insertions(+)
diff
The Zc* standard extension for code reduction introduces new extensions.
This patch adds support for Zca, Zcf, Zcd and Zcb. Zce, Zcmt and Zcmp
are left out of this patch since they are targeting microcontrollers/
embedded CPUs instead of application processors.
Signed-off-by: Clément Léger
---
a
The Zc* spec states that:
"The C extension is the superset of the following extensions:
- Zca
- Zcf if F is specified (RV32 only)
- Zcd if D is specified
As C defines the same instructions as Zca, Zcf and Zcd, the rule is that:
- C always implies Zca
- C+F implies Zcf (RV32 only)"
Add these
As stated by Zc* spec:
"As C defines the same instructions as Zca, Zcf and Zcd, the rule is that:
- C always implies Zca
- C+F implies Zcf (RV32 only)
- C+D implies Zcd"
Add additionnal validation rules to enforce this in dts.
Signed-off-by: Clément Léger
---
.../devicetree/bindings/riscv/c
Add description for Zca, Zcf, Zcd and Zcb extensions which are part the
Zc* standard extensions for code size reduction. Additional validation
rules are added since Zcb depends on Zca, Zcf, depends on Zca and F, Zcd
depends on Zca and D and finally, Zcf can not be present on rv64.
Signed-off-by: C
Add support for (yet again) more RVA23U64 missing extensions. Add
support for Zcmop, Zca, Zcf, Zcd and Zcb extensions isa string parsing,
hwprobe and kvm support. Zce, Zcmt and Zcmp extensions have been left
out since they target microcontrollers/embedded CPUs and are not needed
by RVA23U64
This s
The Linux next building selftests with clang and gcc-13 found these
build warnings.
Reported-by: Linux Kernel Functional Testing
Build log:
-
PATH:
Reported build warnings noticed on following test files,
selftests/arm64/mte/
* check_buffer_fill.c
* mte_common_util.c
check_buffer_fill
The Linux next building selftests with clang-17 and gcc-13 found these
build warnings.
Reported-by: Linux Kernel Functional Testing
Build log:
-
PATH:
selftests/arm64/fp
The reported build warnings noticed on following test files.
* sve-ptrace.c
* za-ptrace.c
* zt-ptrace.c
clang-1
On Wed, Apr 17, 2024 at 08:22:22AM -0700, Nathan Chancellor wrote:
> Hi Christian,
>
> I am looking at tools/testing/selftests/clone3/clone3_set_tid.c as part
> of a patch to clean up the uses of 'return ksft_exit_...();' throughout
> the selftests (as they call exit() so they do not return) and I
+CC Eric, Jerry
On Fri, Apr 12, 2024 at 02:49:03PM +0800, Andy Chiu wrote:
> Make has_vector take one argument. This argument represents the minimum
> Vector subextension that the following Vector actions assume.
>
> Also, change riscv_v_first_use_handler(), and boot code that calls
> riscv_v_set
On Fri, Apr 12, 2024 at 02:48:59PM +0800, Andy Chiu wrote:
> Single-letter extensions may also imply multiple subextensions. For
> example, Vector extension implies zve64d, and zve64d implies zve64f.
>
> Extension parsing for "riscv,isa-extensions" has the ability to resolve
> the dependency by ca
On Fri, Apr 12, 2024 at 02:49:01PM +0800, Andy Chiu wrote:
> Add description for Zve32x Zve32f Zve64x Zve64f Zve64d ISA extensions.
>
> Signed-off-by: Andy Chiu
Technically this should be before the patch using them in the kernel,
but
Acked-by: Conor Dooley
Cheers,
Conor.
signature.asc
Desc
On Fri, Apr 12, 2024 at 02:49:00PM +0800, Andy Chiu wrote:
> Multiple Vector subextensions are added. Also, the patch takes care of
> the dependencies of Vector subextensions by macro expansions. So, if
> some "embedded" platform only reports "zve64f" on the ISA string, the
> parser is able to expa
On Fri, Apr 12, 2024 at 02:48:58PM +0800, Andy Chiu wrote:
> Currently we only support Vector for SMP platforms, that is, all SMP
> cores have the same vlenb. If we happen to detect a mismatching vlen, it
> is better to just fail bootting it up to prevent further race/scheduling
> issues.
>
> Also
On Fri, Apr 12, 2024 at 02:48:57PM +0800, Andy Chiu wrote:
> The function would fail when it detects the calling hart's vlen doesn't
> match the first one's. The boot hart is the first hart calling this
> function during riscv_fill_hwcap, so it is impossible to fail here. Add
> a comment about this
1 - 100 of 112 matches
Mail list logo
