> On 18-Nov-2020, at 10:06 AM, Michael Ellerman wrote:
>
> Athira Rajeev writes:
>> Fix the event code for events: branch-instructions (to PM_BR_FIN),
>> branch-misses (to PM_BR_MPRED_FIN) and cache-misses (to
>> PM_LD_DEMAND_MISS_L1_FIN) for power10 PMU. Update the
>> list of generic events
> On 18-Nov-2020, at 10:02 AM, Michael Ellerman wrote:
>
> Athira Rajeev writes:
>> In Power9, L2/L3 bus events are always available as a
>> "bank" of 4 events. To obtain the counts for any of the
>> l2/l3 bus events in a given bank, the user will have to
>> program PMC4 with corresponding l2
Athira Rajeev writes:
> Fix the event code for events: branch-instructions (to PM_BR_FIN),
> branch-misses (to PM_BR_MPRED_FIN) and cache-misses (to
> PM_LD_DEMAND_MISS_L1_FIN) for power10 PMU. Update the
> list of generic events with this modified event code.
That should be one patch.
> Export
Athira Rajeev writes:
> In Power9, L2/L3 bus events are always available as a
> "bank" of 4 events. To obtain the counts for any of the
> l2/l3 bus events in a given bank, the user will have to
> program PMC4 with corresponding l2/l3 bus event for that
> bank.
>
> Commit 59029136d750 ("powerpc/per
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu (
On Tue, Nov 17, 2020 at 01:51:43PM -0800, Kees Cook wrote:
> On Fri, Nov 13, 2020 at 12:55:53PM -0700, Nathan Chancellor wrote:
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN &&
> > $(ld-option,-
On Tue, Nov 17, 2020 at 11:41:15AM -0800, Nick Desaulniers wrote:
> On Fri, Nov 13, 2020 at 11:56 AM Nathan Chancellor
> wrote:
> >
> > ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
> > along with a few others. Newer versions of ld.lld do not have these
> > warnings. As a r
On Tue, Nov 17, 2020 at 2:16 PM Gustavo A. R. Silva
wrote:
>
> I'm happy to take this series in my tree. I'm planing to send a
> pull-request for -rc5 with more related changes. So, I can include
> this in the same PR.
>
> In the meantime I'll add this to my testing tree, so it can be
> build-tes
David Hildenbrand writes:
> On 17.11.20 16:51, Oscar Salvador wrote:
>> On Wed, Nov 11, 2020 at 03:53:21PM +0100, David Hildenbrand wrote:
>>> Let's revert what we did in case seomthing goes wrong and we return an
>> "something" :-)
>
> Thanks! :)
>
> @Michael, I assume if I don't have to resend,
defconfig
i386defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a006-20201117
i386
llnoconfig
i386 randconfig-a006-20201117
i386 randconfig-a005-20201117
i386 randconfig-a001-20201117
i386 randconfig-a002-20201117
i386 randconfig-a004-20201117
i386 randconfig-a003-202
The previous patch added support for the targetWWPN field in version 2
MADs and vfcFrame structures.
Set the IBMVFC_CAN_SEND_VF_WWPN bit in our capabailites flag during NPIV
Login to inform the VIOS that this client supports the feature.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/i
The FC iu and response payloads are located at different offsets
depending on the ibmvfc_cmd version. This is a result of the version 2
vfcFrame definition adding an extra 64bytes of reserved space to the
structure prior to the payloads.
Add helper routines to determine the current vfcFrame versio
Several version 2 MADs and the version 2 vfcFrame structures introduced
a new targetWWPN field for better identification of a target over the
scsi_id.
Set this field and MAD versioning fields when the VIOS advertises the
IBMVFC_HANDLE_VF_WWPN capability.
Signed-off-by: Tyrel Datwyler
---
driver
Introduce a target_wwpn field to several MADs. Its possible that a scsi
ID of a target can change due to some fabric changes. The WWPN of the
scsi target provides a better way to identify the target. Also, add
flags for receiving MAD versioning information and advertising client
support for targetW
Several Management Datagrams (MADs) have been reversioned to add a targetWWPN
field that is intended to better identify a target over in place of the scsi_id.
This patchset adds the new protocol definitions and implements support for using
the new targetWWPN field and exposing the capability to the
The virtual FC frame command exchanged with the VIOS is used for device
reset and command abort TMF as well as normally queued commands. When
initializing the ibmvfc_cmd there are several elements of the command
that are set the same way regardless of the command type.
Deduplicate code by moving t
Testing the NPIV Login response capabilities is a long winded process of
dereferencing the vhost->login_buf->resp.capabilities field, then byte
swapping that value to host endian, and performing the bitwise test.
Currently we only ever check this in ibmvfc_cancel_all(), but follow-up
patches will n
On 11/17/20 11:16 AM, Tyrel Datwyler wrote:
> Several Management Datagrams (MADs) have been reversioned to add a targetWWPN
> field that is intended to better identify a target over a scsi_id. Further, a
> couple new MADs have been introduced to the protocol to be used for
> negotiation
> of chann
On 11/17/20 2:21 PM, Brian King wrote:
> On 11/17/20 4:14 PM, Brian King wrote:
>> On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
>>> The FC iu and response payloads are located at different offsets
>>> depending on the ibmvfc_cmd version. This is a result of the version 2
>>> vfcFrame definition addin
On 11/17/20 2:14 PM, Brian King wrote:
> On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
>> The FC iu and response payloads are located at different offsets
>> depending on the ibmvfc_cmd version. This is a result of the version 2
>> vfcFrame definition adding an extra 64bytes of reserved space to the
>
On 11/17/20 2:06 PM, Brian King wrote:
> On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
>> @@ -211,7 +214,9 @@ struct ibmvfc_npiv_login_resp {
>> __be64 capabilities;
>> #define IBMVFC_CAN_FLUSH_ON_HALT0x08
>> #define IBMVFC_CAN_SUPPRESS_ABTS0x10
>> -#define IBMVFC_CAN_SUPPORT_CHANNELS 0
On Wed, Nov 18, 2020 at 1:08 AM Nick Desaulniers
wrote:
>
> It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and
> -include compiler_types.h like the main kernel does, though testing that
> produces a whole sea of warnings to cleanup.
(Re; for Gustavo to consider since he took it now)
"Gustavo A. R. Silva" writes:
> On Tue, Nov 17, 2020 at 11:10:26AM -0800, Nick Desaulniers wrote:
>> On Mon, Nov 16, 2020 at 7:02 PM Nathan Chancellor
>> wrote:
>> >
>> > On Sun, Nov 15, 2020 at 08:35:31PM -0800, Nick Desaulniers wrote:
>> > > This reverts commit 6a9dc5fd6170 ("lib: Revert use of
Nick Desaulniers writes:
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. Clang will still warn on cases where there is a
> fallthrough to an immediate break. Add explicit breaks for those cases.
>
> Link: https://github.com/ClangBuiltLinux/linux/
Nick Desaulniers writes:
> The kernel uses `-include` to include include/linux/compiler_types.h
> into all translation units (see scripts/Makefile.lib), which #includes
> compiler_attributes.h.
>
> arch/powerpc/boot/ uses different compiler flags from the rest of the
> kernel. As such, it doesn't
On Tue, Nov 17, 2020 at 02:28:43PM -0800, Nick Desaulniers wrote:
> On Tue, Nov 17, 2020 at 2:16 PM Gustavo A. R. Silva
> wrote:
> >
> > I'm happy to take this series in my tree. I'm planing to send a
> > pull-request for -rc5 with more related changes. So, I can include
> > this in the same PR.
On Mon, 16 Nov 2020 23:09:13 +1100, Michael Ellerman wrote:
> Currently a build with CONFIG_E200=y will fail with:
>
> Error: invalid switch -me200
> Error: unrecognized option -me200
>
> Upstream binutils has never supported an -me200 option. Presumably it
> was supported at some point by ei
On Sun, Nov 15, 2020 at 08:35:30PM -0800, Nick Desaulniers wrote:
> The kernel uses `-include` to include include/linux/compiler_types.h
> into all translation units (see scripts/Makefile.lib), which #includes
> compiler_attributes.h.
>
> arch/powerpc/boot/ uses different compiler flags from the r
On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
> The FC iu and response payloads are located at different offsets
> depending on the ibmvfc_cmd version. This is a result of the version 2
> vfcFrame definition adding an extra 64bytes of reserved space to the
> structure prior to the payloads.
>
> Add h
Everything else in this series looks OK to me.
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
On 11/17/20 4:14 PM, Brian King wrote:
> On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
>> The FC iu and response payloads are located at different offsets
>> depending on the ibmvfc_cmd version. This is a result of the version 2
>> vfcFrame definition adding an extra 64bytes of reserved space to the
>
On Tue, Nov 17, 2020 at 11:10:26AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 16, 2020 at 7:02 PM Nathan Chancellor
> wrote:
> >
> > On Sun, Nov 15, 2020 at 08:35:31PM -0800, Nick Desaulniers wrote:
> > > This reverts commit 6a9dc5fd6170 ("lib: Revert use of fallthrough
> > > pseudo-keyword in l
On 11/11/20 7:04 PM, Tyrel Datwyler wrote:
> @@ -211,7 +214,9 @@ struct ibmvfc_npiv_login_resp {
> __be64 capabilities;
> #define IBMVFC_CAN_FLUSH_ON_HALT 0x08
> #define IBMVFC_CAN_SUPPRESS_ABTS 0x10
> -#define IBMVFC_CAN_SUPPORT_CHANNELS 0x20
> +#define IBMVFC_MAD_VERSION_CAP
On Fri, Nov 13, 2020 at 12:55:52PM -0700, Nathan Chancellor wrote:
> Currently, '--orphan-handling=warn' is spread out across four different
> architectures in their respective Makefiles, which makes it a little
> unruly to deal with in case it needs to be disabled for a specific
> linker version (
On Fri, Nov 13, 2020 at 12:55:53PM -0700, Nathan Chancellor wrote:
> config LD_ORPHAN_WARN
> - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> + def_bool ARCH_WANT_LD_ORPHAN_WARN &&
> $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 11)
On Wed, 11 Nov 2020 07:33:46 -0600, YiFei Zhu wrote:
> This patch series enables bitmap cache for the remaining arches with
> SECCOMP_FILTER, other than MIPS.
>
> I was unable to find any of the arches having subarch-specific NR_syscalls
> macros, so generic NR_syscalls is used. SH's syscall_get_a
The previous patch added support for the targetWWPN field in version 2
MADs and vfcFrame structures.
Set the IBMVFC_CAN_SEND_VF_WWPN bit in our capabailites flag during NPIV
Login to inform the VIOS that this client supports this feature.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/
Several version 2 MADs and the version 2 vfcFrame structures introduced
a new targetWWPN field for better identification of the target then
simply the scsi_id.
Set this field and MAD versioning fields when the VIOS advertises the
IBMVFC_HANDLE_VF_WWPN capability.
Signed-off-by: Tyrel Datwyler
--
Testing the NPIV Login response capabilities is a long winded process of
dereferencing the vhost->login_buf->resp.capabilities field byte
swapping that value to host endian and performing the bitwise test.
Currently we only ever check this in ibmvfc_cancel_all(), but follow-up
patches will need to
The FC iu and response payloads are located at different offsets
depending on the ibmvfc_cmd version. This is a result of the version 2
vfcFrame definition adding an extra 64bytes of reserved space to the
structure prior to the payloads.
Add helper routines to determine the current vfcFrame versio
Several Management Datagrams (MADs) have been reversioned to add a targetWWPN
field that is intended to better identify a target over a scsi_id. Further, a
couple new MADs have been introduced to the protocol to be used for negotiation
of channels/hw queues resources when the VIOS is using SLI-4 ca
Introduce a targetWWPN field to several MADs. Its possible that a scsi
ID of a target can change due to some fabric changes. The WWPN of the
scsi target provides a better way to identify the target. Also, add
flags for receiving MAD versioning information and advertising client
support for targetWW
The virtual FC frame command exchaned with the VIOS is used for device
reset and command abort TMF as well as normally queued commands. When
initializing the ibmvfc_cmd there several elements of the command that
are set the same way regardless of the command type.
Deduplicate code by moving these
The vfcFrame correlation field is 64bit handle that is intended to trace
I/O operations through both the client stack and VIOS stack when the
underlying physical FC adapter supports tagging.
Tag vfcFrames with the associated ibmvfc_event pointer handle.
Signed-off-by: Tyrel Datwyler
---
drivers
Remove a superfluous semicolon following a closing function block
bracket.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 01fe65de9086..0cab
Both ibmvfc_show_host_(capabilities|npiv_version) functions retrieve
values from vhost->login_buf.resp buffer. This is the MAD response
buffer from the VIOS and as such any multi-byte non-string values are in
big endian format.
Byte swap these values to host cpu endian format for better human
read
On Wed, Nov 11, 2020 at 03:53:22PM +0100, David Hildenbrand wrote:
> Suggested-by: Michal Hocko
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Rashmica Gupta
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Wei Yang
> Si
On Tue, Nov 17, 2020 at 10:03:29PM +1100, Michael Ellerman wrote:
> Nathan Chancellor writes:
> > Currently, '--orphan-handling=warn' is spread out across four different
> > architectures in their respective Makefiles, which makes it a little
> > unruly to deal with in case it needs to be disabled
On 17.11.20 16:51, Oscar Salvador wrote:
On Wed, Nov 11, 2020 at 03:53:21PM +0100, David Hildenbrand wrote:
Let's revert what we did in case seomthing goes wrong and we return an
"something" :-)
Thanks! :)
@Michael, I assume if I don't have to resend, this can be fixed up?
--
Thanks,
David
On Wed, Nov 11, 2020 at 03:53:21PM +0100, David Hildenbrand wrote:
> Let's revert what we did in case seomthing goes wrong and we return an
"something" :-)
> error - as already done on arm64 and s390x.
>
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Rashmica Gup
On 17.11.20 16:37, Oscar Salvador wrote:
On Wed, Nov 11, 2020 at 03:53:18PM +0100, David Hildenbrand wrote:
@@ -144,7 +147,9 @@ void __ref arch_remove_linear_mapping(u64 start, u64 size)
start = (unsigned long)__va(start);
flush_dcache_range_chunked(start, start + size, FLUSH_CHU
On Wed, Nov 11, 2020 at 03:53:20PM +0100, David Hildenbrand wrote:
> The single caller (arch_remove_linear_mapping()) prints a proper warning
> when this function fails. No need to eventually crash the kernel - let's
> drop this WARN_ON.
>
> Suggested-by: Oscar Salvador
> Cc: Michael Ellerman
>
On Wed, Nov 11, 2020 at 03:53:18PM +0100, David Hildenbrand wrote:
> @@ -144,7 +147,9 @@ void __ref arch_remove_linear_mapping(u64 start, u64 size)
> start = (unsigned long)__va(start);
> flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
>
> + mutex_lock(&linear_m
On Wed, Nov 11, 2020 at 03:53:17PM +0100, David Hildenbrand wrote:
> We want to stop abusing memory hotplug infrastructure in memtrace code
> to perform allocations and remove the linear mapping. Instead we will use
> alloc_contig_pages() and remove the linear mapping manually.
>
> Let's factor ou
On Wed, Nov 11, 2020 at 03:53:16PM +0100, David Hildenbrand wrote:
> Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory
> tracing")
> Cc: sta...@vger.kernel.org# v4.14+
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Rashmica Gupta
> Si
On Wed, Nov 11, 2020 at 03:53:15PM +0100, David Hildenbrand wrote:
> Reported-by: Michael Ellerman
> Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory
> tracing")
> Cc: sta...@vger.kernel.org # v4.14+
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Rashmica G
Commit 2284ffea8f0c ("powerpc/64s/exception: Only test KVM in SRR
interrupts when PR KVM is supported") removed KVM guest tests from
interrupts that do not set HV=1, when PR-KVM is not configured.
This is wrong for HV-KVM HPT guest MMIO emulation case which attempts
to load the faulting instructio
Jordan Niethe writes:
> On Mon, Nov 16, 2020 at 11:02 PM Michael Ellerman wrote:
>>
>> Jordan Niethe writes:
>> > The hardware trace macros which use the memory provided by memtrace are
>> > able to use trace sizes as small as 16MB. Only memblock aligned values
>> > can be removed from each NUMA
Nathan Chancellor writes:
> Currently, '--orphan-handling=warn' is spread out across four different
> architectures in their respective Makefiles, which makes it a little
> unruly to deal with in case it needs to be disabled for a specific
> linker version (in this case, ld.lld 10.0.1).
>
> To mak
On Sat, 14 Nov 2020 21:47:43 +1000, Nicholas Piggin wrote:
> pseries guest kernels have a FWNMI handler for SRESET and MCE NMIs,
> which is basically the same as the regular handlers for those
> interrupts.
>
> The system reset FWNMI handler did not have a KVM guest test in it,
> although it proba
On Thu, 5 Nov 2020 14:47:13 +0100, Cédric Le Goater wrote:
> When accessing the ESB page of a source interrupt, the fault handler
> will retrieve the page address from the XIVE interrupt 'xive_irq_data'
> structure. If the associated KVM XIVE interrupt is not valid, that is
> not allocated at the
On Mon, Nov 09, 2020 at 05:40:52PM +, Christophe Leroy wrote:
> [That is backport of 11522448e641e8f1690c9db06e01985e8e19b401 to linux 5.4]
>
> The kernel expects pte_young() to work regardless of CONFIG_SWAP.
>
> Make sure a minor fault is taken to set _PAGE_ACCESSED when it
> is not already
Hello,
any update on this patch?
Or do we want to increase the timeout here?
Thanks!
On Fri, Oct 23, 2020 at 10:45 AM Po-Hsu Lin wrote:
>
> The eeh-basic test got its own 60 seconds timeout (defined in commit
> 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable
> device.
>
> A
64 matches
Mail list logo
