Implement the test which covers "weird" mmio usage. The test has 4 test
cases:
1) Guest sets IDT/GDT base to point to an MMIO region. Triple fault and
shutdown are expected there.
2) Guest jumps to MMIO address. Fetches from MMIO are not permitted, so
UD is expected there.
3) Guest sets an IDT ent
n the second part, a new test is added:
This test is added to serve as a performance tester and a bug reproducer
for kvm page table code (GPA->HPA mappings), it gives guidance for the
people trying to make some improvement for kvm. And the following
explains
what we can exactly do through t
x27;s appropriate for all architectures. Besides, a helper that
can get granularity of different backing src types(anonumous/thp/hugetlb)
is added, so that we can use the accurate backing src granularity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new test is added:
This
e the accurate backing src granularity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new test is added:
This test is added to serve as a performance tester and a bug reproducer
for kvm page table code (GPA->HPA mappings), it gives guidance for the
people trying to m
On 2021/3/23 23:58, Sean Christopherson wrote:
On Tue, Mar 23, 2021, Yanan Wang wrote:
Hi,
This v5 series can mainly include two parts.
Based on kvm queue branch:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/log/?h=queue
Given the number of Reviewed-by tags, I'm pretty sure you can drop t
On Tue, Mar 23, 2021, Yanan Wang wrote:
> Hi,
> This v5 series can mainly include two parts.
> Based on kvm queue branch:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/log/?h=queue
Given the number of Reviewed-by tags, I'm pretty sure you can drop the "RFC" :-)
e the accurate backing src granularity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new test is added:
This test is added to serve as a performance tester and a bug reproducer
for kvm page table code (GPA->HPA mappings), it gives guidance for the
people trying to m
ty of different backing src types(anonumous/thp/hugetlb)
is added, so that we can use the accurate backing src granularity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new test is added:
This test is added to serve as a performance tester and a bug reproducer
fo
arity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new test is added:
This test is added to serve as a performance tester and a bug reproducer
for kvm page table code (GPA->HPA mappings), it gives guidance for the
people trying to make some improvement for kvm.
listed, it's appropriate for all architectures. Besides, a helper that
can get granularity of different backing src types(anonumous/thp/hugetlb)
is added, so that we can use the accurate backing src granularity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new
ugetlb page sizes are
> listed, it's appropriate for all architectures. Besides, a helper that
> can get granularity of different backing src types(anonumous/thp/hugetlb)
> is added, so that we can use the accurate backing src granularity for
> kinds of alignment or guest memory acce
ty of different backing src types(anonumous/thp/hugetlb)
is added, so that we can use the accurate backing src granularity for
kinds of alignment or guest memory accessing of vcpus.
In the second part, a new test is added:
This test is added to serve as a performance tester and a bug reproducer
fo
Add a new selftest for testing seqnum_ops. This test loads test_seqnum_ops
test module and unloads it. The test module runs tests and prints results
to dmesg.
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
There are a num
On 1/19/21 4:22 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
Acked-by: Yonghong Song
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c | 21 ++-
.../selftests/bpf/bpf_tes
Hi Yonghong
On 01/18/21 09:48, Yonghong Song wrote:
> The original patch code:
>
> +static int trigger_module_test_write(int write_sz)
> +{
> + int fd, err;
> + char *buf = malloc(write_sz);
> +
> + if (!buf)
> + return -ENOMEM;
> +
> + memset(buf, 'a', write_sz);
> +
On 1/18/21 4:18 AM, Qais Yousef wrote:
On 01/16/21 18:11, Yonghong Song wrote:
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/b
On 01/16/21 18:11, Yonghong Song wrote:
>
>
> On 1/16/21 10:21 AM, Qais Yousef wrote:
> > Reuse module_attach infrastructure to add a new bare tracepoint to check
> > we can attach to it as a raw tracepoint.
> >
> > Signed-off-by: Qais Yousef
> > ---
> > .../bpf/bpf_testmod/bpf_testmod-events
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c | 21 ++-
.../selftests/bpf/bpf_tes
On 01/13/21 17:40, Jean-Philippe Brucker wrote:
> On Wed, Jan 13, 2021 at 10:21:31AM +, Qais Yousef wrote:
> > On 01/12/21 12:07, Andrii Nakryiko wrote:
> > > > > > $ sudo ./test_progs -v -t module_attach
> > > > >
> > > > > use -vv when debugging stuff like that with test_progs, it wil
On Wed, Jan 13, 2021 at 10:21:31AM +, Qais Yousef wrote:
> On 01/12/21 12:07, Andrii Nakryiko wrote:
> > > > > $ sudo ./test_progs -v -t module_attach
> > > >
> > > > use -vv when debugging stuff like that with test_progs, it will output
> > > > libbpf detailed logs, that often are very
On 01/12/21 12:07, Andrii Nakryiko wrote:
> > > > $ sudo ./test_progs -v -t module_attach
> > >
> > > use -vv when debugging stuff like that with test_progs, it will output
> > > libbpf detailed logs, that often are very helpful
> >
> > I tried that but it didn't help me. Full output is her
On Tue, Jan 12, 2021 at 11:27 AM Qais Yousef wrote:
>
> On 01/11/21 23:26, Andrii Nakryiko wrote:
> > On Mon, Jan 11, 2021 at 10:20 AM Qais Yousef wrote:
> > >
> > > Reuse module_attach infrastructure to add a new bare tracepoint to check
> > > we can attach to it as a raw tracepoint.
> > >
> > >
On 01/11/21 23:26, Andrii Nakryiko wrote:
> On Mon, Jan 11, 2021 at 10:20 AM Qais Yousef wrote:
> >
> > Reuse module_attach infrastructure to add a new bare tracepoint to check
> > we can attach to it as a raw tracepoint.
> >
> > Signed-off-by: Qais Yousef
> > ---
> >
> > Andrii
> >
> > I was get
On Mon, Jan 11, 2021 at 10:20 AM Qais Yousef wrote:
>
> Reuse module_attach infrastructure to add a new bare tracepoint to check
> we can attach to it as a raw tracepoint.
>
> Signed-off-by: Qais Yousef
> ---
>
> Andrii
>
> I was getting the error below when I was trying to run the test.
> I had
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
Andrii
I was getting the error below when I was trying to run the test.
I had to comment out all related fentry* code to be able to test the raw_tp
st
Add a new selftest for testing seqnum_ops. This test loads test_seqnum_ops
test module and unloads it. The test module runs tests and prints results
to dmesg.
Sequence Number api provides interfaces for unsigned atomic up counters
leveraging atomic_t and atomic64_t ops underneath.
There are a num
Add a new selftest for testing seqnum_ops. This test loads test_seqnum_ops
test module and unloads it. The test module runs tests and prints results
to dmesg.
There are a number of atomic_t usages in the kernel where atomic_t api
is used strictly for counting sequence numbers and other statistical
On Fri, Oct 09, 2020 at 09:55:57AM -0600, Shuah Khan wrote:
> Add a new selftest for testing counter_atomic* Counters API. This test
> load test_counters test modules and unloads.
>
> The test module runs tests and prints results in dmesg.
>
> There are a number of atomic_t usages in the kernel w
Add a new selftest for testing counter_atomic* Counters API. This test
load test_counters test modules and unloads.
The test module runs tests and prints results in dmesg.
There are a number of atomic_t usages in the kernel where atomic_t api
is used strictly for counting and not for managing obj
On Tue, Oct 06, 2020 at 02:44:33PM -0600, Shuah Khan wrote:
> Add a new selftest for testing counter_atomic* Counters API. This test
> load test_counters test modules and unloads.
>
> The test module runs tests and prints results in dmesg.
>
> There are a number of atomic_t usages in the kernel w
Add a new selftest for testing counter_atomic* Counters API. This test
load test_counters test modules and unloads.
The test module runs tests and prints results in dmesg.
There are a number of atomic_t usages in the kernel where atomic_t api
is used strictly for counting and not for managing obj
Add a new selftest for testing counter_simple* and counter_atomic*
Counters API. This test load test_counters test modules and unloads.
The test module runs tests and prints results in dmesg.
There are a number of atomic_t usages in the kernel where atomic_t api
is used strictly for counting and
Add a new selftest for testing counter and counter_atomic counters
api. This test load test_counters test modules and unloads.
The test module runs tests and prints results in dmesg.
There are a number of atomic_t usages in the kernel where atomic_t api
is used strictly for counting and not for m
Hi Linus
On Sun, Apr 26, 2020 at 4:59 AM Li Wang wrote:
From kernel code seems you are right. The pipe indeed takes use of
PAGE_SIZE(ppc64le: 64kB) to split the writes data in the packetized mode
(marked by O_DIRECT). But in the manual page, O_DIRECT indicates us the
PIPE_BUF is the corr
Update .gitignore with new test.
Signed-off-by: Shuah Khan
---
tools/testing/selftests/vm/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/vm/.gitignore
b/tools/testing/selftests/vm/.gitignore
index 63c94d776e89..342c7bc9dc8c 100644
--- a/tools/testing
3.2.99-rc1 review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:f
3.16.54-rc1 review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:
In order to be able to test yield support under preempt, add a test
vector for CRC-T10DIF that is long enough to take multiple iterations
(and thus possible preemption between them) of the primary loop of the
accelerated x86 and arm64 implementations.
Signed-off-by: Ard Biesheuvel
---
crypto/tes
The test compares old text based kprobe API with perf_kprobe.
Here is a sample output of this test:
Creating 1000 kprobes with text-based API takes 6.979683 seconds
Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
Creating 1000 kprobes with perf_kprobe (function name) takes 5.077
Song,
On Tue, Dec 5, 2017 at 2:27 AM, Song Liu wrote:
> The test compares old text based kprobe API with perf_kprobe.
>
> Here is a sample output of this test:
>
> Creating 1000 kprobes with text-based API takes 6.979683 seconds
> Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
The test compares old text based kprobe API with perf_kprobe.
Here is a sample output of this test:
Creating 1000 kprobes with text-based API takes 6.979683 seconds
Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
Creating 1000 kprobes with perf_kprobe (function name) takes 5.077
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Ingo Molnar
> Sent: Friday, November 24, 2017 3:14 AM
> To: linux-kernel@vger.kernel.org
> Subject: [PATCH 01/43] x86/decoder: Add new TEST i
The test compares old text based kprobe API with perf_kprobe.
Here is a sample output of this test:
Creating 1000 kprobes with text-based API takes 6.979683 seconds
Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
Creating 1000 kprobes with perf_kprobe (function name) takes 5.077
On Thu, Nov 30, 2017 at 2:44 AM, Song Liu wrote:
> The test compares old text based kprobe API with PERF_TYPE_KPROBE.
>
> Here is a sample output of this test:
>
> Creating 1000 kprobes with text-based API takes 6.979683 seconds
> Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
>
The test compares old text based kprobe API with PERF_TYPE_KPROBE.
Here is a sample output of this test:
Creating 1000 kprobes with text-based API takes 6.979683 seconds
Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
Creating 1000 kprobes with PERF_TYPE_KPROBE (function name) t
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:f
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:f
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:
From: Masami Hiramatsu
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:8103dd2c
Warning: 8103dd82: f6 09 d8 testb $0xd8,(%rcx)
Warning: objdump says 3 bytes, but insn_get_length() says 2
Warning: decoded and c
On Fri, Nov 24, 2017 at 10:14:06AM +0100, Ingo Molnar wrote:
> From: Masami Hiramatsu
>
> The kbuild test robot reported this build warning:
>
> Warning: arch/x86/tools/test_get_len found difference at
> :8103dd2c
>
> Warning: 8103dd82: f6 09 d8 testb $0xd8,(%rcx)
> Warni
From: Masami Hiramatsu
The kbuild test robot reported this build warning:
Warning: arch/x86/tools/test_get_len found difference at
:8103dd2c
Warning: 8103dd82: f6 09 d8 testb $0xd8,(%rcx)
Warning: objdump says 3 bytes, but insn_get_length() says 2
Warning: decoded and c
The test compares old text based kprobe API with PERF_TYPE_PROBE.
Here is a sample output of this test:
Creating 1000 kprobes with text-based API takes 6.979683 seconds
Cleaning 1000 kprobes with text-based API takes 84.897687 seconds
Creating 1000 kprobes with PERF_TYPE_PROBE (function name) tak
Em Fri, 12 Feb 2016 18:39:54 -0700
Shuah Khan escreveu:
> This test opens user specified Media Device and calls
> MEDIA_IOC_DEVICE_INFO ioctl in a loop once every 10
> seconds. This test is for detecting errors in device
> removal path.
>
> Usage:
> sudo ./media_devkref_test -d /dev/mediaX
>
This test opens user specified Media Device and calls
MEDIA_IOC_DEVICE_INFO ioctl in a loop once every 10
seconds. This test is for detecting errors in device
removal path.
Usage:
sudo ./media_devkref_test -d /dev/mediaX
While test is running, remove the device and
ensure there are no use aft
On Sun, Jan 31, 2016 at 06:48:12PM +0100, Alban Crequy wrote:
> From: Alban Crequy
>
> This adds the selftest "cgroupns_test" in order to test the CGroup
> Namespace patchset.
>
> cgroupns_test creates two child processes. They perform a list of
> actions defined by the array cgroupns_test. This
From: Alban Crequy
This adds the selftest "cgroupns_test" in order to test the CGroup
Namespace patchset.
cgroupns_test creates two child processes. They perform a list of
actions defined by the array cgroupns_test. This array can easily be
extended to more scenarios without adding much code. Th
Quoting Alban Crequy (alban.cre...@gmail.com):
> From: Alban Crequy
>
> This adds the selftest "cgroupns_test" in order to test the CGroup
> Namespace patchset.
>
> cgroupns_test creates two child processes. They perform a list of
> actions defined by the array cgroupns_test. This array can easi
Quoting Alban Crequy (alban.cre...@gmail.com):
> From: Alban Crequy
>
> This adds the selftest "cgroupns_test" in order to test the CGroup
> Namespace patchset.
>
> cgroupns_test creates two child processes. They perform a list of
> actions defined by the array cgroupns_test. This array can easi
From: Alban Crequy
This adds the selftest "cgroupns_test" in order to test the CGroup
Namespace patchset.
cgroupns_test creates two child processes. They perform a list of
actions defined by the array cgroupns_test. This array can easily be
extended to more scenarios without adding much code. Th
This patch adds one more test case called tm-ptrace targeting TM
related ptrace interfaces. This test creates one child process to
run some basic transactions and the parent process attaches the
child to do some ptrace probing using the recently added regset
interfaces. The parent process then comp
Hello Liu Chuansheng,
I have good news, your patch based on /drivers/pci/quirks.c works very
well,
I have no problems after a standby mode, my JMB363/368 SATA/IDE JMicron
Pcie works without problems
Le 06/11/2014 15:33, Liu, Chuansheng a écrit :
> Thanks Barto.
>
> Could you try below patch?
This cleans up the printk() uses and replaces them with pr_* calls,
fixes execution tests to include an icache flush, and adds a new
test for checking the kernel code memory is not writable.
-Kees
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
65 matches
Mail list logo
