Having all the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer, the target specification
generation script, the version detection script and a few
other bits.
Co-developed-by: Alex Gaynor
On Sat, May 7, 2022 at 11:02 AM Herbert Xu wrote:
>
> On Sat, May 07, 2022 at 12:25:32AM +0900, Masahiro Yamada wrote:
> >
> > Sorry, I just noticed the 0day bot had reported the error.
> >
> > I sent v2.(CONFIG_LITTLE_ENDIAN --> CONFIG_CPU_LITTLE_ENDIAN)
> >
> >
Rust support
This is the patch series (v6) to add support for Rust as a second
language to the Linux kernel.
If you are interested in following this effort, please join us in
the mailing list at:
rust-for-li...@vger.kernel.org
and take a look at the project itself at:
When I refactored this Makefile, I accidentally changed the CONFIG
option.
Fixes: b52455a73db9 ("crypto: vmx - Align the short log with Makefile cleanups")
Reported-by: kernel test robot
Signed-off-by: Masahiro Yamada
---
drivers/crypto/vmx/Makefile | 2 +-
1 file changed, 1 insertion(+), 1
On 5/7/2022 1:56 AM, Mike Kravetz wrote:
On 5/5/22 20:39, Baolin Wang wrote:
On 5/6/2022 7:53 AM, Mike Kravetz wrote:
On 4/29/22 01:14, Baolin Wang wrote:
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size
On Sat, May 07, 2022 at 12:25:32AM +0900, Masahiro Yamada wrote:
>
> Sorry, I just noticed the 0day bot had reported the error.
>
> I sent v2.(CONFIG_LITTLE_ENDIAN --> CONFIG_CPU_LITTLE_ENDIAN)
>
> https://lore.kernel.org/lkml/20220506150820.1310802-1-masahi...@kernel.org/
>
>
> Could you
On 5/7/2022 2:55 AM, Mike Kravetz wrote:
On 4/29/22 01:14, Baolin Wang wrote:
On some architectures (like ARM64), it can support CONT-PTE/PMD size
hugetlb, which means it can support not only PMD/PUD size hugetlb:
2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
size
On Fri, 6 May 2022, Niklas Schnelle wrote:
> On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
> >
> > On Thu, 5 May 2022, Bjorn Helgaas wrote:
> >
> > > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > > On
Hi Masahiro,
On Thu, May 05, 2022 at 04:22:29PM +0900, Masahiro Yamada wrote:
>
> This is the third batch of cleanups in this development cycle.
>
> Major changes in v3:
>
> - Generate symbol CRCs as C code, and remove CONFIG_MODULE_REL_CRCS.
>
> Major changes in v2:
>
> - V1 did not work
On Fri, May 06 2022 at 23:41, Thomas Gleixner wrote:
> On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>> Programming an HPET channel as periodic requires setting the
>> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
>> register must be written twice (once for the
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Programming an HPET channel as periodic requires setting the
> HPET_TN_SETVAL bit in the channel configuration. Plus, the comparator
> register must be written twice (once for the comparator value and once for
> the periodic value). Since this
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> + *
> + * Also, NMIs do not have an associated vector. No need for cleanup.
They have a vector and what the heck is this cleanup comment for here?
There is nothing cleanup alike anywhere near.
Adding confusing comments is worse than
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
>
> + if (info->flags & X86_IRQ_ALLOC_AS_NMI) {
> + /* Only one IRQ per NMI */
> + if (nr_irqs != 1)
> + return -EINVAL;
See previous reply.
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> The Intel IOMMU interrupt remapping driver already programs correctly the
> delivery mode of individual irqs as per their irq_data. Improve handling
> of NMIs. Allow only one irq per NMI. Also, it is not necessary to cleanup
> irq vectors after
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Vectors are meaningless when allocating IRQs with NMI as the delivery
> mode.
Vectors are not meaningless. NMI has a fixed vector.
The point is that for a fixed vector there is no vector management
required.
Can you spot the difference?
> In
P2020 also contains Power Management Controller and their registers at
offset 0xe0070 compatible with mpc8548. So add PMC node into DTS include
file fsl/p2020si-post.dtsi
Signed-off-by: Pali Rohár
---
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi | 5 +
1 file changed, 5 insertions(+)
diff
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> There are no restrictions in hardware to set MSI messages with its
> own delivery mode.
"messages with its own" ? Plural/singular confusion.
> Use the mode specified in the provided IRQ hardware
> configuration data. Since most of the IRQs are
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Currently, the delivery mode of all interrupts is set to the mode of the
> APIC driver in use. There are no restrictions in hardware to configure the
> delivery mode of each interrupt individually. Also, certain IRQs need
> to be
Ricardo,
On Thu, May 05 2022 at 16:59, Ricardo Neri wrote:
> Certain types of interrupts, such as NMI, do not have an associated vector.
> They, however, target specific CPUs. Thus, when assigning the destination
> CPU, it is beneficial to select the one with the lowest number of
> vectors.
Why
On 5/3/22 03:03, Gerald Schaefer wrote:
> On Tue, 3 May 2022 10:19:46 +0800
> Baolin Wang wrote:
>
>>
>>
>> On 5/2/2022 10:02 PM, Gerald Schaefer wrote:
>>> On Sat, 30 Apr 2022 11:22:33 +0800
>>> Baolin Wang wrote:
>>>
On 4/30/2022 4:02 AM, Gerald Schaefer wrote:
> On Fri, 29
On 4/29/22 01:14, Baolin Wang wrote:
> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> size specified.
>
> When unmapping a hugetlb page,
A handful of WAN drivers use custom napi weights,
switch them to the new API.
Signed-off-by: Jakub Kicinski
---
CC: qiang.z...@nxp.com
CC: k...@pm.waw.pl
CC: m...@dev.tdt.de
CC: linuxppc-dev@lists.ozlabs.org
CC: linux-...@vger.kernel.org
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
Capture register data for secondary CPUs in crash_smp_send_stop()
instead of doing it much later in crash_kexec_prepare_cpus() function
with another set of NMI IPIs to secondary CPUs. This change avoids
unnecessarily tricky post processing of data to get the right
backtrace for these CPUs.
Hi Herbert,
On Fri, May 6, 2022 at 7:23 PM Herbert Xu wrote:
>
> On Sun, May 01, 2022 at 10:07:49PM +0900, Masahiro Yamada wrote:
> > I notieced the log is not properly aligned:
> >
> > PERL drivers/crypto/vmx/aesp8-ppc.S
> > CC [M] fs/xfs/xfs_reflink.o
> > PERL
I notieced the log is not properly aligned:
PERL drivers/crypto/vmx/aesp8-ppc.S
CC [M] fs/xfs/xfs_reflink.o
PERL drivers/crypto/vmx/ghashp8-ppc.S
CC [M] drivers/crypto/vmx/aes.o
Add some spaces after 'PERL'.
While I was here, I cleaned up the Makefile:
- Merge the two similar rules
Hi Geert,
> > Sane access would require a single CPU instruction to read or write from
> > the configuration space. To access the conventional PCI configuration
> > space in a direct linear manner you need 256 * 21 * 8 * 256 = 10.5MiB of
> > address space. Such amount of address space seems
Hi David
On Fri, May 6, 2022 at 4:05 PM David Laight wrote:
> From: Geert Uytterhoeven
> > Sent: 06 May 2022 14:09
> > > The same is really true for other bus type - including ISA and EISA.
> > > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > > are in the ACPI tables??_
> >
Hi Maciej,
On Fri, May 6, 2022 at 4:44 PM Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, David Laight wrote:
> > > It was retrofitted in that x86 systems already existed for ~15 years when
> > > PCI came into picture. Therefore the makers of the CPU ISA couldn't have
> > > envisaged the need
On Fri, 6 May 2022, David Laight wrote:
> > It was retrofitted in that x86 systems already existed for ~15 years when
> > PCI came into picture. Therefore the makers of the CPU ISA couldn't have
> > envisaged the need for config access instructions like they did for memory
> > and port access.
Alexey Kardashevskiy writes:
> When KVM_CAP_PPC_ENABLE_HCALL was introduced, H_GET_TCE and H_PUT_TCE
> were already implemented and enabled by default; however H_GET_TCE
> was missed out on PR KVM (probably because the handler was in
> the real mode code at the time).
>
> This enables H_GET_TCE
From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> >
On Fri, 6 May 2022, Geert Uytterhoeven wrote:
> A lng time ago, it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(),
From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
>
> > > The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean approach is most welcome IMHO. Thank
Hi Athira,
Some comments below :)
Athira Rajeev writes:
> Add caps support under "/sys/bus/event_source/devices//"
> for powerpc. This directory can be used to expose some of the
> specific features that powerpc PMU supports to the user.
> Example: pmu_name. The name of PMU registered will
On Fri, 6 May 2022, Arnd Bergmann wrote:
> > So what happens if the instruction is given an I/O rather than memory BAR
> > as the relevant argument? Is the address space indicator bit (bit #0)
> > simply ignored or what?
>
> Not sure. My best guess is that it would actually work as you'd
On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> >
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the
On Fri, 6 May 2022, David Laight wrote:
> > The PCI configuration space was retrofitted into x86 systems (and is
> > accessed in an awkward manner with them), but with a new design such a
> > clean approach is most welcome IMHO. Thank you for your explanation.
>
> Actually I think x86 was the
On Fri, May 6, 2022 at 2:56 PM David Laight wrote:
> From: Maciej W. Rozycki
> > Sent: 06 May 2022 13:27
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the address phase. So
On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390
From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architecture
On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390
On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> >
> > (It has
On Fri, 6 May 2022, Arnd Bergmann wrote:
> > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > pattern put on the bus/in the TLP in the address phase. So what is there
> > inherent to the s390 architecture that prevents that different bit pattern
> > from being used?
>
Le 18/04/2022 à 08:40, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> Since c93d4f6ecf4b ("powerpc/ftrace: Add module_trampoline_target()
>> for PPC32"), __ftrace_make_nop() for PPC32 is very similar to the
>> one for PPC64.
>>
>> Same for __ftrace_make_call().
>>
>> Make them common.
>>
Le 18/04/2022 à 09:00, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> Since commit 0c0c52306f47 ("powerpc: Only support DYNAMIC_FTRACE not
>> static"), CONFIG_DYNAMIC_FTRACE is always selected when
>> CONFIG_FUNCTION_TRACER is selected.
>>
>> To avoid confusion and have the reader wonder
On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> On Thu, 5 May 2022, Arnd Bergmann wrote:
> I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> bus used with s390 hardware, right?
>
> (It has to be PCI/PCIe, because other than x86/IA-64 host buses there are
>
On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
>
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
>
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
On Sun, May 01, 2022 at 10:07:49PM +0900, Masahiro Yamada wrote:
> I notieced the log is not properly aligned:
>
> PERL drivers/crypto/vmx/aesp8-ppc.S
> CC [M] fs/xfs/xfs_reflink.o
> PERL drivers/crypto/vmx/ghashp8-ppc.S
> CC [M] drivers/crypto/vmx/aes.o
>
> Add some spaces after
On Thu, May 05, 2022 at 06:09:45PM -0700, Josh Poimboeuf wrote:
> With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative
> pointers are calculated weirdly: based on the beginning of the bug_entry
> struct address, rather than their respective pointer addresses.
>
> Make the relative
On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I'm hearing that generic powerpc kernels have to run both on machines
> > that have I/O port space and those that don't. That makes me think
> > s390 could do something similar.
>
> No, this is actually the current situation, and it makes absolutely
On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what
Hi Kajol,
Thanks for the patch. Minor review comment below:
Kajol Jain writes:
> With CONFIG_FORTIFY_SOURCE enabled, string functions will also perform
> dynamic checks for string size which can panic the kernel,
> like incase of overflow detection.
>
> In papr_scm, papr_scm_pmu_check_events
> On 05-May-2022, at 10:51 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, May 05, 2022 at 03:30:39PM +0530, Athira Rajeev escreveu:
>> Perf BPF filter test fails in environment where "clang"
>> is not installed.
>>
>> Test failure logs:
>>
>> <<>>
>> 42: BPF filter:
>>
> On 05-May-2022, at 10:54 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, May 05, 2022 at 03:09:59PM +0530, Athira Rajeev escreveu:
>> /proc/cpuinfo provides information about type of processor, number
>> of CPU's etc. Reading /proc/cpuinfo file outputs useful information
>> by field name
Josh Poimboeuf writes:
> With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative
> pointers are calculated weirdly: based on the beginning of the bug_entry
> struct address, rather than their respective pointer addresses.
>
> Make the relative pointers less surprising to both humans
Trying to remove asm/ppc_asm.h from all places that don't need it
leads to several failures linked to firmware_has_feature().
To fix it, include asm/firmware.h in all files using
firmware_has_feature()
All users found with:
git grep -L "firmware\.h" ` git grep -l
asm/ppc_asm.h is not needed in any of the header it is included.
It is only needed by irq.c. Include it there and remove it from
other headers.
word-at-a-time.h only need ex_table.h, so include it instead.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/io.h | 1 -
On Thu, 5 May 2022, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > >
> > > > The main goal is to avoid c), which is what
From: Athira Rajeev
Add new folder for enabling perf event code tests which
includes checking for group constraints, valid/invalid events,
also checks for event excludes, alternatives so on. A new folder
"event_code_tests", is created under "selftests/powerpc/pmu".
Also updates the
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for indirect branch type. Testcase checks if IFM bits are
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface for ISA v3.1 platform.
Signed-off-by:
The testcase checks if the transalation of a generic hardware cache
event is done properly via perf interface. The hardware cache events
has type as PERF_TYPE_HW_CACHE and each event points to raw event
code id.
Testcase checks different combination of cache level,
cache event operation type and
Thresh compare bits for a event is used to program thresh compare
field in Monitor Mode Control Register A (MMCRA: 9-18 bits for
power9 and MMCRA: 8-18 bits for power10). When scheduling events
as a group, all events in that group should match value in
thresh compare bits. Otherwise event open for
Thresh select bits in the event code is used to program thresh_sel
field in Monitor Mode Control Register A (MMCRA: 45-47). When scheduling
events as a group, all events in that group should match value in these
bits. Otherwise event open for the sibling events will fail.
Testcase uses event code
Thresh control bits in the event code is used to program thresh_ctl
field in Monitor Mode Control Register A (MMCRA: 48-55). When scheduling
events as a group, all events in that group should match value in these
bits. Otherwise event open for the sibling events will fail.
Testcase uses event
From: Athira Rajeev
Testcase for reserved bits in Monitor Mode Control
Register A (MMCRA) Random Sampling Mode (SM) value.
As per Instruction Set Architecture (ISA), the values
0x5, 0x9, 0xD, 0x19, 0x1D, 0x1A, 0x1E are reserved
for sampling mode field. Test that having these reserved
bit values
Unit and pmu bits in the event code is used to program unit and pmc
fields in Monitor Mode Control Register 1 (MMCR1). For power9 platform,
incase unit field value is within 6 to 9, one of the event in the group
should use PMC4. Otherwise event_open should fail for that group.
Signed-off-by:
Data and instruction cache qualifier bits in the event code is
used to program cache select field in Monitor Mode Control
Register 1 (MMCR1: 16-17). When scheduling events as a group, all
events in that group should match value in these bits. Otherwise
event open for the sibling events will fail.
The testcase uses "instructions" event to generate the
samples and fetch Monitor Mode Control Register A (MMCRA)
when overflow. Branch History Rolling Buffer(bhrb) disable bit
is part of MMCRA which need to be verified by perf interface.
Testcase checks if the bhrb disable bit of MMCRA register is
In power10, L2L3 select bits in the event code is used to
program l2l3_sel field in Monitor Mode Control Register 0
(MMCR0: 56-60). When scheduling events as a group,
all events in that group should match value in these bits.
Otherwise event open for the sibling events will fail.
Testcase uses
From: Athira Rajeev
Testcase to ensure that using invalid event in generic
event for PERF_TYPE_HARDWARE will fail. Invalid generic
events in power10 are:
- PERF_COUNT_HW_BUS_CYCLES
- PERF_COUNT_HW_STALLED_CYCLES_FRONTEND
- PERF_COUNT_HW_STALLED_CYCLES_BACKEND
- PERF_COUNT_HW_REF_CPU_CYCLES
From: Athira Rajeev
Platform specific PMU supports alternative event for some
of the event codes. During perf_event_open, it any event
group doesn't match constraint check criteria, further lookup
is done to find alternative event. Code checks to see if
it is possible to schedule event as group
From: Athira Rajeev
Platform specific PMU supports alternative event for some
of the event codes. During perf_event_open, it any event
group doesn't match constraint check criteria, further lookup
is done to find alternative event. Code checks to see if
it is possible to schedule event as group
From: Athira Rajeev
Testcase for reserved bits in Monitor Mode
Control Register A (MMCRA) thresh_ctl bits.
For MMCRA[48:51]/[52:55]) Threshold Start/Stop,
0b/0b is reserved.
Signed-off-by: Athira Rajeev
---
.../powerpc/pmu/event_code_tests/Makefile | 2 +-
From: Athira Rajeev
Some of the events are blacklisted in power9. The list
of blacklisted events are noted in power9-events-list.h
When trying to do event open for any of these blacklisted
event will cause a failure. Testcase ensures that using
blacklisted events will cause event_open to fail in
From: Athira Rajeev
Some of the bits in the event code is reserved
for specific platforms. Event code bits 52-59 are
reserved in power9, whereas in power10, these are used
for programming Monitor Mode Control Register 3 (MMCR3).
Bit 9 in event code is reserved in power9, whereas it
is used for
From: Athira Rajeev
Events with different "sample" field values which is
used to program Monitor Mode Control Register A (MMCRA)
in a group will fail to schedule. Testcase uses event with
load only sampling mode as group leader and event with
store only sampling as sibling event. So that it can
From: Athira Rajeev
Testcase for group constraint check for radix_scope_qual
field which is used to program Monitor Mode Control Register
(MMCR1) bit 18. All events in the group should match radix_scope_qual
bit, otherwise event_open for the group should fail. Testcase uses
"0x14242"
From: Athira Rajeev
Testcase for group constraint check when using events
with same PMC. Multiple events in a group asking for
same PMC should fail. Testcase uses "0x22C040" on PMC2
as leader and also subling which is expected to fail.
Using PMC1 for sibling event should pass the test.
From: Athira Rajeev
Testcase for group constraint check for number of
counters in use. The number of programmable counters
is from PMC1 to PMC4. Testcase uses four events with PMC1
to PMC4 and 5th event without any PMC which is expected to fail
since it is exceeding the number of counters in
From: Athira Rajeev
Events using Performance Monitor Counter 5 (PMC5) and
Performance Monitor Counter 6 (PMC6) should be excluded
from constraint check when scheduled along with group of
events. Example, combination of PMC5, PMC6, and an event
with cache bit will succeed to schedule though first
From: Athira Rajeev
Events using Performance Monitor Counter 5 (PMC5) and
Performance Monitor Counter 6 (PMC6) can't have other fields in
event code like cache bits, thresholding or marked bit. PMC5 and PMC6
only supports base events: ie 500fa and 600f4. Other combinations
should fail. Testcase
The testcase uses "instructions" event to generate the
samples and fetch Monitor Mode Control Register A (MMCRA)
when overflow. Branch History Rolling Buffer(bhrb) disable bit
is part of MMCRA which need to be verified by perf interface.
Incase sample is not of branch type, bhrb disable bit is
From: Athira Rajeev
The testcase uses event code "0x21c040" to verify
the settings for different fields in Monitor Mode Control
Register 1 (MMCR1). The fields include PMCxSEL, PMCXCOMB
PMCxUNIT, cache. Checks if these fields are translated
correctly via perf interface to MMCR1
Signed-off-by:
From: Athira Rajeev
For PERF_SAMPLE_BRANCH_STACK sample type, different
branch_sample_type, ie branch filters are supported.
All the branch filters are not supported in powerpc.
Example, power10 platform supports any, ind_call and
cond branch filters. Whereas, it is different in power9.
Testcase
From: Athira Rajeev
With sampling, --intr-regs option is used for capturing
interrupt regs. When --intr-regs option is used, PMU code
uses is_sier_available() function which uses PMU flags in
the code. In environment where platform specific PMU is
not registered, PMU flags is not defined. A fix
From: Athira Rajeev
While enabling branch stack for an event, BHRB (Branch History
Rolling Buffer) filter is set using bhrb_filter_map() callback.
This callback is not defined for cases like generic_compat_pmu
or in case where there is no PMU registered. A fix was added
in kernel to address a
From: Athira Rajeev
The platform check for selftest support "check_pvr_for_sampling_tests"
is specific to sampling tests which includes PVR check, presence of
PMU and extended regs support. Extended regs support is needed for
sampling tests which tests whether PMU registers are programmed
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for conditional branch type. Testcase checks if IFM bits is
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface for ISA v3.1 platform.
Signed-off-by:
The testcase uses "instructions" event to check if the
Instruction filtering mode(IFM) bits are programmed correctly
for type any branch. Testcase checks if IFM bits is
programmed correctly to Monitor Mode Control Register A (MMCRA)
via perf interface.
Signed-off-by: Kajol Jain
---
Add support for sample type as PERF_SAMPLE_BRANCH_STACK in sampling
tests. This change is a precursor/helper for sampling testcases, that
test branck stack feature in perf interface.
Signed-off-by: Kajol Jain
---
.../powerpc/pmu/sampling_tests/misc.c | 21 ++-
1 file
The testcase uses event code 0x35340401e0 for load
only sampling, to verify the settings of thresh compare field
in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9
and MMCRA: 8-18 bits for power10). Testcase checks if the thresh compare
field is programmed correctly via perf interface
From: Athira Rajeev
The /proc/self/auxv contains information about "platform" on any
system. Also "base platform" which is an indication about platform
string corresponding to the real PVR. When systems are booted in
compat mode, say, power10 booted in power9 mode, "platform" will
point to
In power10, threshold compare field is not part of the raw
event code and provided via event attribute config1.
Hence add the mask and shift bits based on event attribute
config1, to extract the threshold compare value for power10
Also add a new function called get_thresh_cmp_val to compute
and
Patch series extends the perf interface selftests
to cover scenarios for event code checking,
group constraints, and also thresholding/branch related
interface tests in sampling area.
In this series, patches 1 to 14 adds additional tests under
"powerpc/sampling_tests". These adds support for
On Thu, May 05, 2022 at 06:09:45PM -0700, Josh Poimboeuf wrote:
> With CONFIG_GENERIC_BUG_RELATIVE_POINTERS, the addr/file relative
> pointers are calculated weirdly: based on the beginning of the bug_entry
> struct address, rather than their respective pointer addresses.
>
> Make the relative
When KVM_CAP_PPC_ENABLE_HCALL was introduced, H_GET_TCE and H_PUT_TCE
were already implemented and enabled by default; however H_GET_TCE
was missed out on PR KVM (probably because the handler was in
the real mode code at the time).
This enables H_GET_TCE by default. While at this, this wraps
the
kernel test robot reported kernel-doc warning for rm_host_ipi_action():
>> arch/powerpc/kvm/book3s_hv_rm_xics.c:887: warning: This comment starts with
>> '/**', but isn't a kernel-doc comment. Refer
>> Documentation/doc-guide/kernel-doc.rst
* Host Operations poked by RM KVM
Since the
Thresh compare bits for a event is used to program thresh compare
field in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9).
When scheduling events as a group, all events in that group should
match value in threshold bits (like thresh compare, thresh control,
thresh select). Otherwise
Thresh compare bits for a event is used to program thresh compare
field in Monitor Mode Control Register A (MMCRA: 8-18 bits for power10).
When scheduling events as a group, all events in that group should
match value in threshold bits. Otherwise event open for the sibling
events should fail. But
99 matches
Mail list logo
