* Re: [PATCH 4/4] powerpc/powernv: Remove POWER9 PVR version check for entry and uaccess flushes
From: Joel Stanley @ 2021-05-05 1:43 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1620119643.r94ggot8r7.astroid@bobo.none>
On Tue, 4 May 2021 at 09:16, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> > On Mon, 3 May 2021 at 13:04, Nicholas Piggin <npiggin@gmail.com> wrote:
> >>
> >> These aren't necessarily POWER9 only, and it's not to say some new
> >> vulnerability may not get discovered on other processors for which
> >> we would like the flexibility of having the workaround enabled by
> >> firmware.
> >>
> >> Remove the restriction that they only apply to POWER9.
> >
> > I was wondering how these worked which led me to reviewing your patch.
> > From what I could see, these are enabled by default (SEC_FTR_DEFAULT
> > in arch/powerpc/include/asm/security_features.h), so unless all
> > non-POWER9 machines have set the "please don't" bit in their firmware
> > this patch will enable the feature for those machines. Is that what
> > you wanted?
>
> Yes. POWER7/8 should be affected (it's similar mechanism that requires
> the meltdown RFI flush, which those processors need).
>
> POWER10 we haven't released a bare metal firmware with the right bits
> yet. Not urgent at the moment but wouldn't hurt to specify them and
> add the Linux code for them.
Thanks for the explanation. This could go in the commit message if you re-spin.
Reviewed-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Stephen Rothwell @ 2021-05-05 1:39 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Anshuman Khandual
[-- Attachment #1: Type: text/plain, Size: 4133 bytes --]
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/Kconfig
between commit:
c6b05f4e233c ("powerpc/kconfig: Restore alphabetic order of the selects under CONFIG_PPC")
from the powerpc tree and commits:
fd7d5c273c43 ("mm: generalize HUGETLB_PAGE_SIZE_VARIABLE")
301ba77ae03c ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/Kconfig
index ab17a56c3d10,d4333049b813..000000000000
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -118,11 -118,10 +118,13 @@@ config PP
# Please keep this list sorted alphabetically.
#
select ARCH_32BIT_OFF_T if PPC32
+ select ARCH_ENABLE_MEMORY_HOTPLUG
+ select ARCH_ENABLE_MEMORY_HOTREMOVE
+ select ARCH_HAS_COPY_MC if PPC64
select ARCH_HAS_DEBUG_VIRTUAL
+ select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEVMEM_IS_ALLOWED
+ select ARCH_HAS_DMA_MAP_DIRECT if PPC_PSERIES
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
@@@ -163,8 -162,9 +165,8 @@@
select BUILDTIME_TABLE_SORT
select CLONE_BACKWARDS
select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
- select DMA_OPS_BYPASS if PPC64
select DMA_OPS if PPC64
+ select DMA_OPS_BYPASS if PPC64
- select ARCH_HAS_DMA_MAP_DIRECT if PPC64 && PPC_PSERIES
select DYNAMIC_FTRACE if FUNCTION_TRACER
select EDAC_ATOMIC_SCRUB
select EDAC_SUPPORT
@@@ -182,15 -181,12 +184,15 @@@
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select GENERIC_TIME_VSYSCALL
- select GENERIC_GETTIMEOFDAY
+ select GENERIC_VDSO_TIME_NS
select HAVE_ARCH_AUDITSYSCALL
- select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
+ select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
+ select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
+ select HAVE_ARCH_KFENCE if PPC32
select HAVE_ARCH_KGDB
select HAVE_ARCH_MMAP_RND_BITS
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
@@@ -231,19 -227,23 +233,20 @@@
select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 && PPC_BOOK3S)
- select HAVE_HARDLOCKUP_DETECTOR_ARCH if (PPC64 && PPC_BOOK3S)
- select HAVE_OPTPROBES if PPC64
+ select HAVE_OPTPROBES
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
- select HAVE_HARDLOCKUP_DETECTOR_PERF if PERF_EVENTS && HAVE_PERF_EVENTS_NMI && !HAVE_HARDLOCKUP_DETECTOR_ARCH
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
- select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
- select MMU_GATHER_RCU_TABLE_FREE
- select MMU_GATHER_PAGE_SIZE
select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_RELIABLE_STACKTRACE if PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN
+ select HAVE_RELIABLE_STACKTRACE
+ select HAVE_RSEQ
select HAVE_SOFTIRQ_ON_OWN_STACK
+ select HAVE_STACKPROTECTOR if PPC32 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r2)
+ select HAVE_STACKPROTECTOR if PPC64 && $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=r13)
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
- select HAVE_IRQ_TIME_ACCOUNTING
- select HAVE_RSEQ
++ select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: Fix crashes when toggling stf barrier
From: Nathan Lynch @ 2021-05-04 22:44 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, anton, npiggin, dja
In-Reply-To: <20210504134250.890401-1-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> -void do_stf_barrier_fixups(enum stf_barrier_type types)
> +static int __do_stf_barrier_fixups(void *data)
> {
> + enum stf_barrier_type types = (enum stf_barrier_type)data;
> +
> do_stf_entry_barrier_fixups(types);
> do_stf_exit_barrier_fixups(types);
> +
> + return 0;
> +}
> +
> +void do_stf_barrier_fixups(enum stf_barrier_type types)
> +{
> + /*
> + * The call to the fallback entry flush, and the fallback/sync-ori exit
> + * flush can not be safely patched in/out while other CPUs are executing
> + * them. So call __do_stf_barrier_fixups() on one CPU while all other CPUs
> + * spin in the stop machine core with interrupts hard disabled.
> + */
> + stop_machine_cpuslocked(__do_stf_barrier_fixups, (void *)types, NULL);
Would it be preferable to avoid the explicit casts:
stop_machine_cpuslocked(__do_stf_barrier_fixups, &types, NULL);
...
static int __do_stf_barrier_fixups(void *data)
{
enum stf_barrier_type *types = data;
do_stf_entry_barrier_fixups(*types);
do_stf_exit_barrier_fixups(*types);
?
post_mobility_fixup() does cpus_read_unlock() before calling
pseries_setup_security_mitigations(), I think that will need to be
changed?
^ permalink raw reply
* Re: [PATCH v4] pseries/drmem: update LMBs after LPM
From: Nathan Lynch @ 2021-05-04 22:30 UTC (permalink / raw)
To: Laurent Dufour
Cc: Tyrel Datwyler, linux-kernel, paulus, Aneesh Kumar K . V,
linuxppc-dev
In-Reply-To: <20210504092038.8514-1-ldufour@linux.ibm.com>
Hi Laurent,
Bear with me while I work through the commit message:
Laurent Dufour <ldufour@linux.ibm.com> writes:
> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
> updated by the hypervisor in the case the NUMA topology of the LPAR's
> memory is updated.
Yes, the RTAS functions ibm,update-nodes and ibm,update-properties,
which the OS invokes after resuming, may bring in updated properties
under the ibm,dynamic-reconfiguration-memory node, including the
ibm,associativity-lookup-arrays property.
> This is caught by the kernel,
"Caught" makes me think this is an error condition, as in catching an
exception. I guess "handled" better conveys your meaning?
> but the memory's node is updated because
> there is no way to move a memory block between nodes.
"The memory's node" refers the ibm,dynamic-reconfiguration-memory DT
node, yes? Or is it referring to Linux's NUMA nodes? ("move a memory
block between nodes" in your statement here refers to Linux's NUMA
nodes, that much is clear to me.)
I am failing to follow the cause->effect relationship stated. True,
changing a block's node assignment while it's in use isn't safe. I don't
see why that implies that "the memory's node is updated"? In fact this
seems contradictory.
This statement makes more sense to me if I change it to "the memory's
node is _not_ updated" -- is this what you intended?
> If later a memory block is added or removed, drmem_update_dt() is called
> and it is overwriting the DT node to match the added or removed LMB.
I understand this, but I will expand on it.
dlpar_memory()
-> dlpar_memory_add_by_count()
-> dlpar_add_lmb()
-> update_lmb_associativity_index()
... lmb->aa_index = <value>
-> drmem_update_dt()
update_lmb_associativity_index() retrieves the firmware description of
the new block, and sets the aa_index of the matching entry in the
drmem_info array to the value matching the firmware description.
Then, drmem_update_dt() walks the drmem_info array and synthesizes a new
/ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory-v2 property based
on the recently updated information in that array.
> But the LMB's associativity node has not been updated after the DT
> node update and thus the node is overwritten by the Linux's topology
> instead of the hypervisor one.
So, an example of the problem is:
1. VM migrates. On resume, ibm,associativity-lookup-arrays is changed
via ibm,update-properties. Entries in the drmem_info array remain
unchanged, with aa_index values that correspond to the source
system's ibm,associativity-lookup-arrays property, now inaccessible.
2. A memory block is added. We look up the new block's entry in the
drmem_info array, and set the aa_index to the value matching the
current ibm,associativity-lookup-arrays.
3. Then, the ibm,associativity-lookup-arrays property is completely
regenerated from the drmem_info array, which reflects a mixture of
information from the source and destination systems.
Do I understand correctly?
> Introduce a hook called when the ibm,dynamic-reconfiguration-memory node is
> updated to force an update of the LMB's associativity. However, ignore the
> call to that hook when the update has been triggered by drmem_update_dt().
> Because, in that case, the LMB tree has been used to set the DT property
> and thus it doesn't need to be updated back. Since drmem_update_dt() is
> called under the protection of the device_hotplug_lock and the hook is
> called in the same context, use a simple boolean variable to detect that
> call.
This strikes me as almost a revert of e978a3ccaa71 ("powerpc/pseries:
remove obsolete memory hotplug DT notifier code").
I'd rather avoid smuggling through global state information that ought
to be passed in function parameters, if it should be passed around at
all. Despite having (IMO) relatively simple responsibilities, this code
is difficult to change and review; adding this property makes it
worse. If the structure of the code is pushing us toward this kind of
compromise, then the code probably needs more fundamental changes.
I'm probably forgetting something -- can anyone remind me why we need an
array of these:
struct drmem_lmb {
u64 base_addr;
u32 drc_index;
u32 aa_index;
u32 flags;
};
which is just a less efficient representation of what's already in the
device tree? If we got rid of it, would this problem disappear?
^ permalink raw reply
* Re: [PATCH net v3] ibmvnic: Continue with reset if set link down failed
From: Dany Madden @ 2021-05-04 20:24 UTC (permalink / raw)
To: Lijun Pan
Cc: Thomas Falcon, netdev, Paul Mackerras, Jakub Kicinski,
Sukadev Bhattiprolu, linuxppc-dev, David S. Miller
In-Reply-To: <CAOhMmr5ucF3pa4jp9RLEzJNs29oVT0qAXmywNnd+Xe2seoRJfg@mail.gmail.com>
On 2021-05-04 12:31, Lijun Pan wrote:
> On Tue, May 4, 2021 at 2:27 PM Lijun Pan <lijunp213@gmail.com> wrote:
>>
>> On Tue, May 4, 2021 at 2:14 PM Dany Madden <drt@linux.ibm.com> wrote:
>> >
>> > When ibmvnic gets a FATAL error message from the vnicserver, it marks
>> > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
>> > FATAL reset fails and a transmission timeout reset follows, the CRQ is
>> > still inactive, ibmvnic's attempt to set link down will also fail. If
>> > ibmvnic abandons the reset because of this failed set link down and this
>> > is the last reset in the workqueue, then this adapter will be left in an
>> > inoperable state.
>> >
>> > Instead, make the driver ignore this link down failure and continue to
>> > free and re-register CRQ so that the adapter has an opportunity to
>> > recover.
>> >
>> > Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
>> > Signed-off-by: Dany Madden <drt@linux.ibm.com>
>> > Reviewed-by: Rick Lindsley <ricklind@linux.ibm.com>
>> > Reviewed-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
>> > ---
>> > Changes in V2:
>> > - Update description to clarify background for the patch
>> > - Include Reviewed-by tags
>> > Changes in V3:
>> > - Add comment above the code change
>> > ---
>> > drivers/net/ethernet/ibm/ibmvnic.c | 11 +++++++++--
>> > 1 file changed, 9 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
>> > index 5788bb956d73..9e005a08d43b 100644
>> > --- a/drivers/net/ethernet/ibm/ibmvnic.c
>> > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
>> > @@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
>> > rtnl_unlock();
>> > rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
>> > rtnl_lock();
>> > - if (rc)
>> > - goto out;
>> > +
>> > + /* Attempted to set the link down. It could fail if the
>> > + * vnicserver has already torn down the CRQ. We will
>> > + * note it and continue with reset to reinit the CRQ.
>> > + */
>> > + if (rc) {
>> > + netdev_dbg(netdev,
>> > + "Setting link down failed rc=%d. Continue anyway\n", rc);
>> > + }
>>
>> There are other places which check and rely on the return value of
>> this function. Your change makes that inconsistent. Can you stop
>
> To be more specific, __ibmvnic_close, __ibmvnic_open both call this
> set_link_state.
Inconsistent would have been not checking for the rc at all. Here we
checked and noted it that there are times that it's ok to continue.
>
>> posting new versions and soliciting the maintainer to accept it before
>> there is material change? There are many ways to make reset
>> successful. I think this is the worst approach of all.
Can you show me a patch that is better than this one, that has gone thru
a 30+ hours of testing?
>>
>>
>> >
>> > if (adapter->state == VNIC_OPEN) {
>> > /* When we dropped rtnl, ibmvnic_open() got
>> > --
>> > 2.18.2
>> >
^ permalink raw reply
* Re: [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()
From: Nick Desaulniers @ 2021-05-04 19:56 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Nathan Chancellor, linuxppc-dev, clang-built-linux
In-Reply-To: <CAKwvOd=kU=gOci7y1CjZaKw+w5H3kZ_CfzGG0=r+Fs33hLV4uw@mail.gmail.com>
On Fri, Apr 30, 2021 at 2:33 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Tue, Apr 27, 2021 at 1:42 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > On Mon, Apr 26, 2021 at 11:39 PM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> > >
> > > As you can see, CLANG doesn't save/restore 'lr' allthought 'lr' is explicitely listed in the
> > > registers clobbered by the inline assembly:
> >
> > Ah, thanks for debugging this. Will follow up in
> > https://bugs.llvm.org/show_bug.cgi?id=50147.
>
> Looks like there's a fix posted for LLVM in: https://reviews.llvm.org/D101657
>
> Though trying to test it in QEMU, I'm hitting some assertion failure
> booting a kernel (even without that patch to LLVM):
> qemu-system-ppc: ../../hw/pci/pci.c:253: pci_bus_change_irq_level:
> Assertion `irq_num >= 0' failed.
> That's with
> QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-9)
>
> I didn't see anything in https://bugs.launchpad.net/qemu/ about it,
> but figured I'd share in case that assertion failure looked familiar
> to anyone.
Nathan pointed out some previous reports; looks like others are
hitting this, too:
https://github.com/ClangBuiltLinux/linux/issues/1345#issuecomment-830451276
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v2 net-next resend] ibmvnic: remove default label from to_string switch
From: Lijun Pan @ 2021-05-04 19:39 UTC (permalink / raw)
To: Michal Suchanek
Cc: netdev, linux-kernel, Thomas Falcon, Paul Mackerras, Dany Madden,
Jakub Kicinski, Sukadev Bhattiprolu, linuxppc-dev,
David S. Miller
In-Reply-To: <20210504191923.32313-1-msuchanek@suse.de>
On Tue, May 4, 2021 at 2:19 PM Michal Suchanek <msuchanek@suse.de> wrote:
>
> This way the compiler warns when a new value is added to the enum but
> not to the string translation like:
>
> drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
> drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value 'VNIC_FOOBAR' not handled in switch [-Wswitch]
> switch (state) {
> ^~~~~~
> drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string':
> drivers/net/ethernet/ibm/ibmvnic.c:1935:2: warning: enumeration value 'VNIC_RESET_FOOBAR' not handled in switch [-Wswitch]
> switch (reason) {
> ^~~~~~
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> Acked-by: Lijun Pan <lijunp213@gmail.com>
> ---
> v2: Fix typo in commit message
> ---
Hi Michal,
Thank you for reposting the patch and including the Ack-by tag. I
think you need to wait till next Tuesday or so when net-next reopens,
then you can repost the patch.
http://vger.kernel.org/~davem/net-next.html.
Thanks,
Lijun
^ permalink raw reply
* Re: [PATCH net v3] ibmvnic: Continue with reset if set link down failed
From: Lijun Pan @ 2021-05-04 19:31 UTC (permalink / raw)
To: Dany Madden
Cc: Thomas Falcon, netdev, Paul Mackerras, Jakub Kicinski,
Sukadev Bhattiprolu, linuxppc-dev, David S. Miller
In-Reply-To: <CAOhMmr5T_BLkqGspnzck=xtiX0rPABv8oX4=LCRbH00T8-B6qw@mail.gmail.com>
On Tue, May 4, 2021 at 2:27 PM Lijun Pan <lijunp213@gmail.com> wrote:
>
> On Tue, May 4, 2021 at 2:14 PM Dany Madden <drt@linux.ibm.com> wrote:
> >
> > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> > FATAL reset fails and a transmission timeout reset follows, the CRQ is
> > still inactive, ibmvnic's attempt to set link down will also fail. If
> > ibmvnic abandons the reset because of this failed set link down and this
> > is the last reset in the workqueue, then this adapter will be left in an
> > inoperable state.
> >
> > Instead, make the driver ignore this link down failure and continue to
> > free and re-register CRQ so that the adapter has an opportunity to
> > recover.
> >
> > Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> > Signed-off-by: Dany Madden <drt@linux.ibm.com>
> > Reviewed-by: Rick Lindsley <ricklind@linux.ibm.com>
> > Reviewed-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
> > ---
> > Changes in V2:
> > - Update description to clarify background for the patch
> > - Include Reviewed-by tags
> > Changes in V3:
> > - Add comment above the code change
> > ---
> > drivers/net/ethernet/ibm/ibmvnic.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
> > index 5788bb956d73..9e005a08d43b 100644
> > --- a/drivers/net/ethernet/ibm/ibmvnic.c
> > +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> > @@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> > rtnl_unlock();
> > rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
> > rtnl_lock();
> > - if (rc)
> > - goto out;
> > +
> > + /* Attempted to set the link down. It could fail if the
> > + * vnicserver has already torn down the CRQ. We will
> > + * note it and continue with reset to reinit the CRQ.
> > + */
> > + if (rc) {
> > + netdev_dbg(netdev,
> > + "Setting link down failed rc=%d. Continue anyway\n", rc);
> > + }
>
> There are other places which check and rely on the return value of
> this function. Your change makes that inconsistent. Can you stop
To be more specific, __ibmvnic_close, __ibmvnic_open both call this
set_link_state.
> posting new versions and soliciting the maintainer to accept it before
> there is material change? There are many ways to make reset
> successful. I think this is the worst approach of all.
>
>
> >
> > if (adapter->state == VNIC_OPEN) {
> > /* When we dropped rtnl, ibmvnic_open() got
> > --
> > 2.18.2
> >
^ permalink raw reply
* Re: [PATCH net v3] ibmvnic: Continue with reset if set link down failed
From: Lijun Pan @ 2021-05-04 19:27 UTC (permalink / raw)
To: Dany Madden
Cc: Thomas Falcon, netdev, Paul Mackerras, Jakub Kicinski,
Sukadev Bhattiprolu, linuxppc-dev, David S. Miller
In-Reply-To: <20210504191142.2872696-1-drt@linux.ibm.com>
On Tue, May 4, 2021 at 2:14 PM Dany Madden <drt@linux.ibm.com> wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive, ibmvnic's attempt to set link down will also fail. If
> ibmvnic abandons the reset because of this failed set link down and this
> is the last reset in the workqueue, then this adapter will be left in an
> inoperable state.
>
> Instead, make the driver ignore this link down failure and continue to
> free and re-register CRQ so that the adapter has an opportunity to
> recover.
>
> Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> Signed-off-by: Dany Madden <drt@linux.ibm.com>
> Reviewed-by: Rick Lindsley <ricklind@linux.ibm.com>
> Reviewed-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
> ---
> Changes in V2:
> - Update description to clarify background for the patch
> - Include Reviewed-by tags
> Changes in V3:
> - Add comment above the code change
> ---
> drivers/net/ethernet/ibm/ibmvnic.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
> index 5788bb956d73..9e005a08d43b 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
> rtnl_unlock();
> rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
> rtnl_lock();
> - if (rc)
> - goto out;
> +
> + /* Attempted to set the link down. It could fail if the
> + * vnicserver has already torn down the CRQ. We will
> + * note it and continue with reset to reinit the CRQ.
> + */
> + if (rc) {
> + netdev_dbg(netdev,
> + "Setting link down failed rc=%d. Continue anyway\n", rc);
> + }
There are other places which check and rely on the return value of
this function. Your change makes that inconsistent. Can you stop
posting new versions and soliciting the maintainer to accept it before
there is material change? There are many ways to make reset
successful. I think this is the worst approach of all.
>
> if (adapter->state == VNIC_OPEN) {
> /* When we dropped rtnl, ibmvnic_open() got
> --
> 2.18.2
>
^ permalink raw reply
* [PATCH v2 net-next resend] ibmvnic: remove default label from to_string switch
From: Michal Suchanek @ 2021-05-04 19:19 UTC (permalink / raw)
To: netdev
Cc: Sukadev Bhattiprolu, Lijun Pan, linux-kernel, Thomas Falcon,
Paul Mackerras, Dany Madden, Jakub Kicinski, Michal Suchanek,
linuxppc-dev, David S. Miller
In-Reply-To: <20210503.134721.2149322673805635760.davem@davemloft.net>
This way the compiler warns when a new value is added to the enum but
not to the string translation like:
drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value 'VNIC_FOOBAR' not handled in switch [-Wswitch]
switch (state) {
^~~~~~
drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:1935:2: warning: enumeration value 'VNIC_RESET_FOOBAR' not handled in switch [-Wswitch]
switch (reason) {
^~~~~~
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Acked-by: Lijun Pan <lijunp213@gmail.com>
---
v2: Fix typo in commit message
---
drivers/net/ethernet/ibm/ibmvnic.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5788bb956d73..4d439413f6d9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -846,9 +846,8 @@ static const char *adapter_state_to_string(enum vnic_state state)
return "REMOVING";
case VNIC_REMOVED:
return "REMOVED";
- default:
- return "UNKNOWN";
}
+ return "UNKNOWN";
}
static int ibmvnic_login(struct net_device *netdev)
@@ -1946,9 +1945,8 @@ static const char *reset_reason_to_string(enum ibmvnic_reset_reason reason)
return "TIMEOUT";
case VNIC_RESET_CHANGE_PARAM:
return "CHANGE_PARAM";
- default:
- return "UNKNOWN";
}
+ return "UNKNOWN";
}
/*
--
2.26.2
^ permalink raw reply related
* [PATCH net v3] ibmvnic: Continue with reset if set link down failed
From: Dany Madden @ 2021-05-04 19:11 UTC (permalink / raw)
To: davem, kuba; +Cc: tlfalcon, netdev, paulus, drt, sukadev, linuxppc-dev
When ibmvnic gets a FATAL error message from the vnicserver, it marks
the Command Respond Queue (CRQ) inactive and resets the adapter. If this
FATAL reset fails and a transmission timeout reset follows, the CRQ is
still inactive, ibmvnic's attempt to set link down will also fail. If
ibmvnic abandons the reset because of this failed set link down and this
is the last reset in the workqueue, then this adapter will be left in an
inoperable state.
Instead, make the driver ignore this link down failure and continue to
free and re-register CRQ so that the adapter has an opportunity to
recover.
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Dany Madden <drt@linux.ibm.com>
Reviewed-by: Rick Lindsley <ricklind@linux.ibm.com>
Reviewed-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
---
Changes in V2:
- Update description to clarify background for the patch
- Include Reviewed-by tags
Changes in V3:
- Add comment above the code change
---
drivers/net/ethernet/ibm/ibmvnic.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5788bb956d73..9e005a08d43b 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2017,8 +2017,15 @@ static int do_reset(struct ibmvnic_adapter *adapter,
rtnl_unlock();
rc = set_link_state(adapter, IBMVNIC_LOGICAL_LNK_DN);
rtnl_lock();
- if (rc)
- goto out;
+
+ /* Attempted to set the link down. It could fail if the
+ * vnicserver has already torn down the CRQ. We will
+ * note it and continue with reset to reinit the CRQ.
+ */
+ if (rc) {
+ netdev_dbg(netdev,
+ "Setting link down failed rc=%d. Continue anyway\n", rc);
+ }
if (adapter->state == VNIC_OPEN) {
/* When we dropped rtnl, ibmvnic_open() got
--
2.18.2
^ permalink raw reply related
* [RFC PATCH v5 15/16] watchdog: Expose lockup_detector_reconfigure()
From: Ricardo Neri @ 2021-05-04 19:05 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov
Cc: Ravi V. Shankar, Tony Luck, Ashok Raj, Peter Zijlstra (Intel),
Ricardo Neri, x86, Ricardo Neri, Nicholas Piggin, linux-kernel,
Andi Kleen, Stephane Eranian, Suravee Suthikulpanit,
H. Peter Anvin, Andi Kleen, Andrew Morton, linuxppc-dev
In-Reply-To: <20210504190526.22347-1-ricardo.neri-calderon@linux.intel.com>
When there are more than one implementation of the NMI watchdog, there may
be situations in which switching from one to another is needed. For
if the time-stamp counter becomes unstable, the HPET-based NMI watchdog
an no longer be used.
Switching to another hardlockup detector can be done cleanly by updating
the arch-specific stub and then reconfiguring the whole lockup detector.
Expose lockup_detector_reconfigure() to achieve this goal.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
Changes since v4:
* Switching to the perf-based lockup detector under the hood is hacky.
Instead, reconfigure the whole lockup detector.
Changes since v3:
* None
Changes since v2:
* Introduced this patch.
Changes since v1:
* N/A
---
include/linux/nmi.h | 2 ++
kernel/watchdog.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index cf12380e51b3..73827a477288 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -16,6 +16,7 @@ void lockup_detector_init(void);
void lockup_detector_soft_poweroff(void);
void lockup_detector_cleanup(void);
bool is_hardlockup(void);
+void lockup_detector_reconfigure(void);
extern int watchdog_user_enabled;
extern int nmi_watchdog_user_enabled;
@@ -37,6 +38,7 @@ extern int sysctl_hardlockup_all_cpu_backtrace;
static inline void lockup_detector_init(void) { }
static inline void lockup_detector_soft_poweroff(void) { }
static inline void lockup_detector_cleanup(void) { }
+static inline void lockup_detector_reconfigure(void) { }
#endif /* !CONFIG_LOCKUP_DETECTOR */
#ifdef CONFIG_SOFTLOCKUP_DETECTOR
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 4615064ee282..96f06938dc83 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -531,7 +531,7 @@ int lockup_detector_offline_cpu(unsigned int cpu)
return 0;
}
-static void lockup_detector_reconfigure(void)
+void lockup_detector_reconfigure(void)
{
cpus_read_lock();
watchdog_nmi_stop();
@@ -577,7 +577,7 @@ static __init void lockup_detector_setup(void)
}
#else /* CONFIG_SOFTLOCKUP_DETECTOR */
-static void lockup_detector_reconfigure(void)
+void lockup_detector_reconfigure(void)
{
cpus_read_lock();
watchdog_nmi_stop();
--
2.17.1
^ permalink raw reply related
* [RFC PATCH v5 12/16] watchdog/hardlockup: Use parse_option_str() to handle "nmi_watchdog"
From: Ricardo Neri @ 2021-05-04 19:05 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov
Cc: Ravi V. Shankar, Tony Luck, Ashok Raj, Peter Zijlstra (Intel),
Ricardo Neri, x86, Ricardo Neri, Nicholas Piggin, linux-kernel,
Andi Kleen, Stephane Eranian, Suravee Suthikulpanit,
H. Peter Anvin, Andi Kleen, Andrew Morton, linuxppc-dev
In-Reply-To: <20210504190526.22347-1-ricardo.neri-calderon@linux.intel.com>
Prepare hardlockup_panic_setup() to handle a comma-separated list of
options. Thus, it can continue parsing its own command-line options while
ignoring paremeters that are relevant only to specific implementations of
the hardlockup detector. Such implementations may use an early_param to
parse their own options.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
Changes since v4:
* None
Changes since v3:
* None
Changes since v2:
* Introduced this patch.
Changes since v1:
* None
---
kernel/watchdog.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 107bc38b1945..4615064ee282 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -73,13 +73,13 @@ void __init hardlockup_detector_disable(void)
static int __init hardlockup_panic_setup(char *str)
{
- if (!strncmp(str, "panic", 5))
+ if (parse_option_str(str, "panic"))
hardlockup_panic = 1;
- else if (!strncmp(str, "nopanic", 7))
+ else if (parse_option_str(str, "nopanic"))
hardlockup_panic = 0;
- else if (!strncmp(str, "0", 1))
+ else if (parse_option_str(str, "0"))
nmi_watchdog_user_enabled = 0;
- else if (!strncmp(str, "1", 1))
+ else if (parse_option_str(str, "1"))
nmi_watchdog_user_enabled = 1;
return 1;
}
--
2.17.1
^ permalink raw reply related
* [RFC PATCH v5 05/16] watchdog/hardlockup: Decouple the hardlockup detector from perf
From: Ricardo Neri @ 2021-05-04 19:05 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov
Cc: Ravi V. Shankar, Tony Luck, Ashok Raj, Peter Zijlstra (Intel),
Ricardo Neri, x86, Ricardo Neri, Nicholas Piggin, linux-kernel,
Andi Kleen, Stephane Eranian, Suravee Suthikulpanit,
H. Peter Anvin, Andi Kleen, Andrew Morton, linuxppc-dev
In-Reply-To: <20210504190526.22347-1-ricardo.neri-calderon@linux.intel.com>
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Group and wrap in #ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF all the code
specific to perf: create and manage perf events, stop and start the perf-
based detector.
The generic portion of the detector (monitor the timers' thresholds, check
timestamps and detect hardlockups as well as the implementation of
arch_touch_nmi_watchdog()) is now selected with the new intermediate config
symbol CONFIG_HARDLOCKUP_DETECTOR_CORE.
The perf-based implementation of the detector selects the new intermediate
symbol. Other implementations should do the same.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
Changes since v4:
* None
Changes since v3:
* Squashed into this patch a previous patch to make
arch_touch_nmi_watchdog() part of the core detector code.
Changes since v2:
* Undid split of the generic hardlockup detector into a separate file.
(Thomas Gleixner)
* Added a new intermediate symbol CONFIG_HARDLOCKUP_DETECTOR_CORE to
select generic parts of the detector (Paul E. McKenney,
Thomas Gleixner).
Changes since v1:
* Make the generic detector code with CONFIG_HARDLOCKUP_DETECTOR.
---
include/linux/nmi.h | 5 ++++-
kernel/Makefile | 2 +-
kernel/watchdog_hld.c | 32 ++++++++++++++++++++------------
lib/Kconfig.debug | 4 ++++
4 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 1b68f48ad440..cf12380e51b3 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -94,8 +94,11 @@ static inline void hardlockup_detector_disable(void) {}
# define NMI_WATCHDOG_SYSCTL_PERM 0444
#endif
-#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF)
+#if defined(CONFIG_HARDLOCKUP_DETECTOR_CORE)
extern void arch_touch_nmi_watchdog(void);
+#endif
+
+#if defined(CONFIG_HARDLOCKUP_DETECTOR_PERF)
extern void hardlockup_detector_perf_stop(void);
extern void hardlockup_detector_perf_restart(void);
extern void hardlockup_detector_perf_disable(void);
diff --git a/kernel/Makefile b/kernel/Makefile
index e8a6715f38dc..03ac041abfff 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -95,7 +95,7 @@ obj-$(CONFIG_FAIL_FUNCTION) += fail_function.o
obj-$(CONFIG_KGDB) += debug/
obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o
-obj-$(CONFIG_HARDLOCKUP_DETECTOR_PERF) += watchdog_hld.o
+obj-$(CONFIG_HARDLOCKUP_DETECTOR_CORE) += watchdog_hld.o
obj-$(CONFIG_SECCOMP) += seccomp.o
obj-$(CONFIG_RELAY) += relay.o
obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index b352e507b17f..bb6435978c46 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -22,12 +22,8 @@
static DEFINE_PER_CPU(bool, hard_watchdog_warn);
static DEFINE_PER_CPU(bool, watchdog_nmi_touch);
-static DEFINE_PER_CPU(struct perf_event *, watchdog_ev);
-static DEFINE_PER_CPU(struct perf_event *, dead_event);
-static struct cpumask dead_events_mask;
static unsigned long hardlockup_allcpu_dumped;
-static atomic_t watchdog_cpus = ATOMIC_INIT(0);
notrace void arch_touch_nmi_watchdog(void)
{
@@ -98,14 +94,6 @@ static inline bool watchdog_check_timestamp(void)
}
#endif
-static struct perf_event_attr wd_hw_attr = {
- .type = PERF_TYPE_HARDWARE,
- .config = PERF_COUNT_HW_CPU_CYCLES,
- .size = sizeof(struct perf_event_attr),
- .pinned = 1,
- .disabled = 1,
-};
-
void inspect_for_hardlockups(struct pt_regs *regs)
{
if (__this_cpu_read(watchdog_nmi_touch) == true) {
@@ -157,6 +145,24 @@ void inspect_for_hardlockups(struct pt_regs *regs)
return;
}
+#ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
+#undef pr_fmt
+#define pr_fmt(fmt) "NMI perf watchdog: " fmt
+
+static DEFINE_PER_CPU(struct perf_event *, watchdog_ev);
+static DEFINE_PER_CPU(struct perf_event *, dead_event);
+static struct cpumask dead_events_mask;
+
+static atomic_t watchdog_cpus = ATOMIC_INIT(0);
+
+static struct perf_event_attr wd_hw_attr = {
+ .type = PERF_TYPE_HARDWARE,
+ .config = PERF_COUNT_HW_CPU_CYCLES,
+ .size = sizeof(struct perf_event_attr),
+ .pinned = 1,
+ .disabled = 1,
+};
+
/* Callback function for perf event subsystem */
static void watchdog_overflow_callback(struct perf_event *event,
struct perf_sample_data *data,
@@ -298,3 +304,5 @@ int __init hardlockup_detector_perf_init(void)
}
return ret;
}
+
+#endif /* CONFIG_HARDLOCKUP_DETECTOR_PERF */
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5918e1686736..08332b5ad4fe 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1021,9 +1021,13 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
+config HARDLOCKUP_DETECTOR_CORE
+ bool
+
config HARDLOCKUP_DETECTOR_PERF
bool
select SOFTLOCKUP_DETECTOR
+ select HARDLOCKUP_DETECTOR_CORE
#
# Enables a timestamp based low pass filter to compensate for perf based
--
2.17.1
^ permalink raw reply related
* [RFC PATCH v5 04/16] watchdog/hardlockup: Define a generic function to detect hardlockups
From: Ricardo Neri @ 2021-05-04 19:05 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Borislav Petkov
Cc: Ravi V. Shankar, Tony Luck, Ashok Raj, Peter Zijlstra (Intel),
Ricardo Neri, x86, Ricardo Neri, Nicholas Piggin, linux-kernel,
Andi Kleen, Stephane Eranian, Suravee Suthikulpanit,
H. Peter Anvin, Andi Kleen, Andrew Morton, linuxppc-dev
In-Reply-To: <20210504190526.22347-1-ricardo.neri-calderon@linux.intel.com>
The procedure to detect hardlockups is independent of the underlying
mechanism that generates the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.
For this purpose, move the bulk of watchdog_overflow_callback() to the
new function inspect_for_hardlockups(). This function can then be called
from the applicable NMI handlers.
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
Changes since v4:
* None
Changes since v3:
* None
Changes since v2:
* None
Changes since v1:
* None
---
include/linux/nmi.h | 1 +
kernel/watchdog_hld.c | 18 +++++++++++-------
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 750c7f395ca9..1b68f48ad440 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -207,6 +207,7 @@ int proc_nmi_watchdog(struct ctl_table *, int , void *, size_t *, loff_t *);
int proc_soft_watchdog(struct ctl_table *, int , void *, size_t *, loff_t *);
int proc_watchdog_thresh(struct ctl_table *, int , void *, size_t *, loff_t *);
int proc_watchdog_cpumask(struct ctl_table *, int, void *, size_t *, loff_t *);
+void inspect_for_hardlockups(struct pt_regs *regs);
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
#include <asm/nmi.h>
diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index 247bf0b1582c..b352e507b17f 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -106,14 +106,8 @@ static struct perf_event_attr wd_hw_attr = {
.disabled = 1,
};
-/* Callback function for perf event subsystem */
-static void watchdog_overflow_callback(struct perf_event *event,
- struct perf_sample_data *data,
- struct pt_regs *regs)
+void inspect_for_hardlockups(struct pt_regs *regs)
{
- /* Ensure the watchdog never gets throttled */
- event->hw.interrupts = 0;
-
if (__this_cpu_read(watchdog_nmi_touch) == true) {
__this_cpu_write(watchdog_nmi_touch, false);
return;
@@ -163,6 +157,16 @@ static void watchdog_overflow_callback(struct perf_event *event,
return;
}
+/* Callback function for perf event subsystem */
+static void watchdog_overflow_callback(struct perf_event *event,
+ struct perf_sample_data *data,
+ struct pt_regs *regs)
+{
+ /* Ensure the watchdog never gets throttled */
+ event->hw.interrupts = 0;
+ inspect_for_hardlockups(regs);
+}
+
static int hardlockup_detector_event_create(void)
{
unsigned int cpu = smp_processor_id();
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
From: Dany Madden @ 2021-05-04 19:05 UTC (permalink / raw)
To: Rick Lindsley
Cc: Michal Suchánek, Lijun Pan, netdev, Lijun Pan, Tom Falcon,
Paul Mackerras, Jakub Kicinski, Sukadev Bhattiprolu, linuxppc-dev,
David Miller
In-Reply-To: <9e46d7ad-55dd-7caf-0a39-344b80bdceb3@linux.vnet.ibm.com>
On 2021-04-22 19:26, Rick Lindsley wrote:
> On 4/22/21 10:21 AM, Michal Suchánek wrote:
>
>> Merging do_reset and do_hard_reset might be a good code cleanup which
>> is
>> out of the scope of this fix.
>
> I agree, on both points. Accepting the patch, and improving the reset
> path are not in conflict with each other.
>
> My position is that improving the reset path is certainly on the table,
> but not with this bug or this fix. Within the context of this
> discovered
> problem, the issue is well understood, the fix is small and addresses
> the
> immediate problem, and it has not generated new bugs under subsequent
> testing. For those reasons, the submitted patch has my support.
>
> Rick
Thanks for all the feedback on the patch. Refactoring the ibmvnic reset
functions is something we plan to evaluate, as this would potentially
simplify the reset code. In the mean time, the proposed patch is simple,
and has been validated in our test environment to solve an issue
resulting in vnic interfaces getting stuck in an offline state following
a vnic timeout reset. Given that, I suggest we merge this patch while we
look at further optimizations in future. I will submit a V3 patch
shortly.
Dany
^ permalink raw reply
* Re: [powerpc:next-test 8/8] arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *'
From: Christophe Leroy @ 2021-05-04 18:41 UTC (permalink / raw)
To: kernel test robot, Michael Ellerman
Cc: clang-built-linux, kbuild-all, linuxppc-dev
In-Reply-To: <202105050231.wjhXNTzu-lkp@intel.com>
Le 04/05/2021 à 20:31, kernel test robot a écrit :
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> head: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
> commit: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c [8/8] powerpc/64s: Fix crashes when toggling entry flush barrier
> config: powerpc-randconfig-r022-20210503 (attached as .config)
> compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install powerpc cross compiling tool for clang build
> # apt-get install binutils-powerpc-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
> git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> git fetch --no-tags powerpc next-test
> git checkout a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=powerpc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer type 'enum stf_barrier_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
> enum stf_barrier_type types = (enum stf_barrier_type)data;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
> enum l1d_flush_type types = (enum l1d_flush_type)data;
> ^~~~~~~~~~~~~~~~~~~~~~~~~
> 2 errors generated.
>
>
> vim +304 arch/powerpc/lib/feature-fixups.c
>
> 301
> 302 static int __do_entry_flush_fixups(void *data)
> 303 {
> > 304 enum l1d_flush_type types = (enum l1d_flush_type)data;
That looks strange to use an enumeration for 'types', as we perform logical ops with it below (eg:
types & L1D_FLUSH_ORI).
I think it should be an int.
> 305 unsigned int instrs[3], *dest;
> 306 long *start, *end;
> 307 int i;
> 308
> 309 instrs[0] = 0x60000000; /* nop */
> 310 instrs[1] = 0x60000000; /* nop */
> 311 instrs[2] = 0x60000000; /* nop */
> 312
> 313 i = 0;
> 314 if (types == L1D_FLUSH_FALLBACK) {
> 315 instrs[i++] = 0x7d4802a6; /* mflr r10 */
> 316 instrs[i++] = 0x60000000; /* branch patched below */
> 317 instrs[i++] = 0x7d4803a6; /* mtlr r10 */
> 318 }
> 319
> 320 if (types & L1D_FLUSH_ORI) {
> 321 instrs[i++] = 0x63ff0000; /* ori 31,31,0 speculation barrier */
> 322 instrs[i++] = 0x63de0000; /* ori 30,30,0 L1d flush*/
> 323 }
> 324
> 325 if (types & L1D_FLUSH_MTTRIG)
> 326 instrs[i++] = 0x7c12dba6; /* mtspr TRIG2,r0 (SPR #882) */
> 327
> 328 start = PTRRELOC(&__start___entry_flush_fixup);
> 329 end = PTRRELOC(&__stop___entry_flush_fixup);
> 330 for (i = 0; start < end; start++, i++) {
> 331 dest = (void *)start + *start;
> 332
> 333 pr_devel("patching dest %lx\n", (unsigned long)dest);
> 334
> 335 patch_instruction((struct ppc_inst *)dest, ppc_inst(instrs[0]));
> 336
> 337 if (types == L1D_FLUSH_FALLBACK)
> 338 patch_branch((struct ppc_inst *)(dest + 1), (unsigned long)&entry_flush_fallback,
> 339 BRANCH_SET_LINK);
> 340 else
> 341 patch_instruction((struct ppc_inst *)(dest + 1), ppc_inst(instrs[1]));
> 342
> 343 patch_instruction((struct ppc_inst *)(dest + 2), ppc_inst(instrs[2]));
> 344 }
> 345
> 346 start = PTRRELOC(&__start___scv_entry_flush_fixup);
> 347 end = PTRRELOC(&__stop___scv_entry_flush_fixup);
> 348 for (; start < end; start++, i++) {
> 349 dest = (void *)start + *start;
> 350
> 351 pr_devel("patching dest %lx\n", (unsigned long)dest);
> 352
> 353 patch_instruction((struct ppc_inst *)dest, ppc_inst(instrs[0]));
> 354
> 355 if (types == L1D_FLUSH_FALLBACK)
> 356 patch_branch((struct ppc_inst *)(dest + 1), (unsigned long)&scv_entry_flush_fallback,
> 357 BRANCH_SET_LINK);
> 358 else
> 359 patch_instruction((struct ppc_inst *)(dest + 1), ppc_inst(instrs[1]));
> 360
> 361 patch_instruction((struct ppc_inst *)(dest + 2), ppc_inst(instrs[2]));
> 362 }
> 363
> 364
> 365 printk(KERN_DEBUG "entry-flush: patched %d locations (%s flush)\n", i,
> 366 (types == L1D_FLUSH_NONE) ? "no" :
> 367 (types == L1D_FLUSH_FALLBACK) ? "fallback displacement" :
> 368 (types & L1D_FLUSH_ORI) ? (types & L1D_FLUSH_MTTRIG)
> 369 ? "ori+mttrig type"
> 370 : "ori type" :
> 371 (types & L1D_FLUSH_MTTRIG) ? "mttrig type"
> 372 : "unknown");
> 373
> 374 return 0;
> 375 }
> 376
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>
^ permalink raw reply
* Re: [PATCH v3 1/2] KVM: PPC: Book3S HV: Sanitise vcpu registers in nested path
From: Fabiano Rosas @ 2021-05-04 18:37 UTC (permalink / raw)
To: Nicholas Piggin, Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc
In-Reply-To: <1620115928.pogd4nj1qc.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> An error message when you try to start the nested guest telling you
> pass -machine cap-htm=off would be better... I guess that should
> really all work with caps etc today though so TM's a bad example.
> But assume we don't have a cap for the bit we disable? Maybe we
> should have caps for all HFSCR bits, or I'm just worried about
> something not very important.
I'm avoiding returning an error from H_ENTER_NESTED at first run
specifically because of this. I think it interferes with L1 migration.
Say we have an L1 that has an workload that involves nested guests. It
can boot and run them just fine (i.e. it uses the same HFSCR value for
its guests as L0). If we migrate that L1 into a host that uses different
HFSCR bits and therefore will always fail the H_ENTER_NESTED, that is
effectively the same as migrating into a host that does not provide
KVM_CAP_PPC_NESTED_HV.
We would need some way to inform the migration code that the remote host
will not allow L1 to run nested guests with that particular HFSCR value
so that it can decide whether that host is a suitable migration
target. Otherwise we're migrating the guest into a host that will not
allow its operation to continue.
Returning an error later on during the nested guest lifetime I think it
is less harmful, but nothing really went wrong with the hypercall. It
did its job and ran L2 like L1 asked, although it ignored some bits. Can
we say that L1 misconfigured L2 when there is no way for L1 to negotiate
which bits it can use? The same set of bits could be considered valid by
another L0. It seems that as long as we hardcode some bits we shouldn't
fail the hcall because of them.
I think since this is all a bit theoretical right now, forwarding a
program interrupt into L1 is a good less permanent solution for the
moment, it does not alter the hcall's API and if we start stumbling into
similar issues in the future we'll have more information then to come up
with a proper solution.
>
> Thanks,
> Nick
^ permalink raw reply
* [powerpc:next-test 8/8] arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *'
From: kernel test robot @ 2021-05-04 18:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: clang-built-linux, kbuild-all, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 4928 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c [8/8] powerpc/64s: Fix crashes when toggling entry flush barrier
config: powerpc-randconfig-r022-20210503 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer type 'enum stf_barrier_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
enum stf_barrier_type types = (enum stf_barrier_type)data;
^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/lib/feature-fixups.c:304:30: error: cast to smaller integer type 'enum l1d_flush_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
enum l1d_flush_type types = (enum l1d_flush_type)data;
^~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
vim +304 arch/powerpc/lib/feature-fixups.c
301
302 static int __do_entry_flush_fixups(void *data)
303 {
> 304 enum l1d_flush_type types = (enum l1d_flush_type)data;
305 unsigned int instrs[3], *dest;
306 long *start, *end;
307 int i;
308
309 instrs[0] = 0x60000000; /* nop */
310 instrs[1] = 0x60000000; /* nop */
311 instrs[2] = 0x60000000; /* nop */
312
313 i = 0;
314 if (types == L1D_FLUSH_FALLBACK) {
315 instrs[i++] = 0x7d4802a6; /* mflr r10 */
316 instrs[i++] = 0x60000000; /* branch patched below */
317 instrs[i++] = 0x7d4803a6; /* mtlr r10 */
318 }
319
320 if (types & L1D_FLUSH_ORI) {
321 instrs[i++] = 0x63ff0000; /* ori 31,31,0 speculation barrier */
322 instrs[i++] = 0x63de0000; /* ori 30,30,0 L1d flush*/
323 }
324
325 if (types & L1D_FLUSH_MTTRIG)
326 instrs[i++] = 0x7c12dba6; /* mtspr TRIG2,r0 (SPR #882) */
327
328 start = PTRRELOC(&__start___entry_flush_fixup);
329 end = PTRRELOC(&__stop___entry_flush_fixup);
330 for (i = 0; start < end; start++, i++) {
331 dest = (void *)start + *start;
332
333 pr_devel("patching dest %lx\n", (unsigned long)dest);
334
335 patch_instruction((struct ppc_inst *)dest, ppc_inst(instrs[0]));
336
337 if (types == L1D_FLUSH_FALLBACK)
338 patch_branch((struct ppc_inst *)(dest + 1), (unsigned long)&entry_flush_fallback,
339 BRANCH_SET_LINK);
340 else
341 patch_instruction((struct ppc_inst *)(dest + 1), ppc_inst(instrs[1]));
342
343 patch_instruction((struct ppc_inst *)(dest + 2), ppc_inst(instrs[2]));
344 }
345
346 start = PTRRELOC(&__start___scv_entry_flush_fixup);
347 end = PTRRELOC(&__stop___scv_entry_flush_fixup);
348 for (; start < end; start++, i++) {
349 dest = (void *)start + *start;
350
351 pr_devel("patching dest %lx\n", (unsigned long)dest);
352
353 patch_instruction((struct ppc_inst *)dest, ppc_inst(instrs[0]));
354
355 if (types == L1D_FLUSH_FALLBACK)
356 patch_branch((struct ppc_inst *)(dest + 1), (unsigned long)&scv_entry_flush_fallback,
357 BRANCH_SET_LINK);
358 else
359 patch_instruction((struct ppc_inst *)(dest + 1), ppc_inst(instrs[1]));
360
361 patch_instruction((struct ppc_inst *)(dest + 2), ppc_inst(instrs[2]));
362 }
363
364
365 printk(KERN_DEBUG "entry-flush: patched %d locations (%s flush)\n", i,
366 (types == L1D_FLUSH_NONE) ? "no" :
367 (types == L1D_FLUSH_FALLBACK) ? "fallback displacement" :
368 (types & L1D_FLUSH_ORI) ? (types & L1D_FLUSH_MTTRIG)
369 ? "ori+mttrig type"
370 : "ori type" :
371 (types & L1D_FLUSH_MTTRIG) ? "mttrig type"
372 : "unknown");
373
374 return 0;
375 }
376
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37797 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Michal Suchánek @ 2021-05-04 18:08 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <1620149664.tj2sjrvaqg.naveen@linux.ibm.com>
On Tue, May 04, 2021 at 11:11:25PM +0530, Naveen N. Rao wrote:
> Nicholas Piggin wrote:
> > Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> > > On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
> > > > On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
> > > > > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
> > > > > > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
> > > > > > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
> > > > > > >> Provide an option to use ELFv2 ABI for big endian builds. This works on
> > > > > > >> GCC and clang (since 2014). It is less well tested and supported by the
> > > > > > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
> > > > > > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
> > > > > > >> userspace.
> > > > > > > > > > Fixes BTFID failure on BE for me and the ELF ABIv2
> > > > kernel boots.
> > > > > > > > What's the BTFID failure? Anything we can do to fix it
> > > > on the v1 ABI or > > at least make it depend on BUILD_ELF_V2?
> > > > > > Looks like symbols are prefixed with a dot in ABIv1 and
> > > > BTFID tool is
> > > > > not aware of that. It can be disabled on ABIv1 easily.
>
> Yes, I think BTF is generated by pahole, so we will need to add support for
> recognising dot symbols there.
There are symbols both with and without dot, and the dwarves
development is headed towards using the ones without dot. Not sure it's
the correct way to resolve it, though.
https://lore.kernel.org/lkml/8c3cbd22-eb26-ea8b-c8bb-35a629d6d2d8@kernel.org/
>
> > > > > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > > > index 678c13967580..e703c26e9b80 100644
> > > > > --- a/lib/Kconfig.debug
> > > > > +++ b/lib/Kconfig.debug
> > > > > @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
> > > > > bool "Generate BTF typeinfo"
> > > > > depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
> > > > > depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
> > > > > + depends on !PPC64 || BUILD_ELF_V2
> > > > > help
> > > > > Generate deduplicated BTF type information from DWARF debug info.
> > > > > Turning this on expects presence of pahole tool, which will convert
> > > > > > > > > > > > > Tested-by: Michal Suchánek <msuchanek@suse.de>
> > > > > > > > > > Also can we enable mprofile on BE now?
> > > > > > > > > > I don't see anything endian-specific in the mprofile
> > > > code at a glance
> > > > > > > but don't have any idea how to test it.
> > > > > > > > AFAIK it's just a different ABI for the _mcount call so
> > > > just running
> > > > > > some ftrace and ftrace with call graph should test it reasonably well.
> > > >
> > > > It does not crash and burn but there are some regressions from LE to BE
> > > > on the ftrace kernel selftest:
> > > >
> > > > @@ -16,10 +16,10 @@
> > > > [n] event tracing - enable/disable with event level files [PASS]
> > > > [n] event tracing - restricts events based on pid notrace filtering [PASS]
> > > > [n] event tracing - restricts events based on pid [PASS]
> > > > -[n] event tracing - enable/disable with subsystem level files [PASS]
> > > > +[n] event tracing - enable/disable with subsystem level files [FAIL]
> > > > [n] event tracing - enable/disable with top level files [PASS]
> > > > -[n] Test trace_printk from module [UNRESOLVED]
> > > > +[n] Test trace_printk from module [FAIL]
> > > > -[n] ftrace - function graph filters with stack tracer [PASS]
> > > > +[n] ftrace - function graph filters with stack tracer [FAIL]
> > > > [n] ftrace - function graph filters [PASS]
> > > > [n] ftrace - function trace with cpumask [PASS]
> > > > [n] ftrace - test for function event triggers [PASS]
> > > > @@ -96,7 +96,8 @@
> > > > [n] (instance) event tracing - enable/disable with event level files [PASS]
> > > > [n] (instance) event tracing - restricts events based on pid notrace filtering [PASS]
> > > > [n] (instance) event tracing - restricts events based on pid [PASS]
> > > > -[n] (instance) event tracing - enable/disable with subsystem level files [PASS]
> > > > +[n] (instance) event tracing - enable/disable with subsystem level files [FAIL]
> > > > +rmdir: failed to remove '/sys/kernel/tracing/instances/ftracetest.mceByV': Device or resource busy
> > > > [n] (instance) ftrace - test for function event triggers [PASS]
> > > > [n] (instance) ftrace - function pid notrace filters [PASS]
> > > > [n] (instance) ftrace - function pid filters [PASS]
> > > >
> > > > I needed to add a test timeout to get this far because
> > > > "event tracing - enable/disable with subsystem level files" gets stuck.
>
> Does that test pass on LE for you? In the past, I have seen some lockups but
> will have to go revisit the tests...
Yes, it's one of the actual regressions where the test is not marked as
XFAIL, UNRESOLVED or UNSUPPORTED on LE.
>
> > >
> > > There is some regression from mprofile on BE ABIv2
> > >
> > > --- ftraceBEv2.txt 2021-05-03 18:11:01.100000000 +0200
> > > +++ ftraceBE.mprofile.txt 2021-05-03 11:27:24.770000000 +0200
> > > @@ -19,7 +19,7 @@
> > > [n] event tracing - enable/disable with subsystem level files [FAIL]
> > > [n] event tracing - enable/disable with top level files [PASS]
> > > [n] Test trace_printk from module [FAIL]
> > > -[n] ftrace - function graph filters with stack tracer [PASS]
> > > +[n] ftrace - function graph filters with stack tracer [FAIL]
> > > [n] ftrace - function graph filters [PASS]
> > > [n] ftrace - function trace with cpumask [PASS]
> > > [n] ftrace - test for function event triggers [PASS]
> > > @@ -31,7 +31,7 @@
> > > [n] ftrace - function profiler with function tracing [PASS]
> > > [n] ftrace - function profiling [PASS]
> > > [n] ftrace - test reading of set_ftrace_filter [PASS]
> > > -[n] ftrace - Max stack tracer [PASS]
> > > +[n] ftrace - Max stack tracer [FAIL]
> > > [n] ftrace - test for function traceon/off triggers [PASS]
> > > [n] ftrace - test tracing error log support [PASS]
> > > [n] Test creation and deletion of trace instances while setting an event [PASS]
> >
> > Hmm, I don't see an obvious case where the stack layout is based on
> > BE when it should be using ELF ABI version, or ftrace_64_mprofile.S
> > depends on LE. +Naveen
>
> Yes, I don't think we ever enabled the stack tracer to work properly on LE
> and -mprofile-kernel. I will take a look tomorrow.
Right, "Max stack tracer" does not show as regression from LE to BE.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v2] powerpc/64: BE option to use ELFv2 ABI for big endian kernels
From: Naveen N. Rao @ 2021-05-04 17:41 UTC (permalink / raw)
To: Michal Suchánek, Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1620118312.ynbufjzv5a.astroid@bobo.none>
Nicholas Piggin wrote:
> Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
>> On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
>>> On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
>>> > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
>>> > > Excerpts from Michal Suchánek's message of May 3, 2021 2:57 am:
>>> > > > On Tue, Apr 28, 2020 at 09:25:17PM +1000, Nicholas Piggin wrote:
>>> > > >> Provide an option to use ELFv2 ABI for big endian builds. This works on
>>> > > >> GCC and clang (since 2014). It is less well tested and supported by the
>>> > > >> GNU toolchain, but it can give some useful advantages of the ELFv2 ABI
>>> > > >> for BE (e.g., less stack usage). Some distros even build BE ELFv2
>>> > > >> userspace.
>>> > > >
>>> > > > Fixes BTFID failure on BE for me and the ELF ABIv2 kernel boots.
>>> > >
>>> > > What's the BTFID failure? Anything we can do to fix it on the v1 ABI or
>>> > > at least make it depend on BUILD_ELF_V2?
>>> >
>>> > Looks like symbols are prefixed with a dot in ABIv1 and BTFID tool is
>>> > not aware of that. It can be disabled on ABIv1 easily.
Yes, I think BTF is generated by pahole, so we will need to add support
for recognising dot symbols there.
>>> >
>>> > Thanks
>>> >
>>> > Michal
>>> >
>>> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>>> > index 678c13967580..e703c26e9b80 100644
>>> > --- a/lib/Kconfig.debug
>>> > +++ b/lib/Kconfig.debug
>>> > @@ -305,6 +305,7 @@ config DEBUG_INFO_BTF
>>> > bool "Generate BTF typeinfo"
>>> > depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>>> > depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
>>> > + depends on !PPC64 || BUILD_ELF_V2
>>> > help
>>> > Generate deduplicated BTF type information from DWARF debug info.
>>> > Turning this on expects presence of pahole tool, which will convert
>>> >
>>> > >
>>> > > >
>>> > > > Tested-by: Michal Suchánek <msuchanek@suse.de>
>>> > > >
>>> > > > Also can we enable mprofile on BE now?
>>> > > >
>>> > > > I don't see anything endian-specific in the mprofile code at a glance
>>> > > > but don't have any idea how to test it.
>>> > >
>>> > > AFAIK it's just a different ABI for the _mcount call so just running
>>> > > some ftrace and ftrace with call graph should test it reasonably well.
>>>
>>> It does not crash and burn but there are some regressions from LE to BE
>>> on the ftrace kernel selftest:
>>>
>>> --- ftraceLE.txt 2021-05-03 11:19:14.830000000 +0200
>>> +++ ftraceBE.txt 2021-05-03 11:27:24.770000000 +0200
>>> @@ -7,8 +7,8 @@
>>> [n] Change the ringbuffer size [PASS]
>>> [n] Snapshot and tracing setting [PASS]
>>> [n] trace_pipe and trace_marker [PASS]
>>> -[n] Test ftrace direct functions against tracers [UNRESOLVED]
>>> -[n] Test ftrace direct functions against kprobes [UNRESOLVED]
>>> +[n] Test ftrace direct functions against tracers [FAIL]
>>> +[n] Test ftrace direct functions against kprobes [FAIL]
Strange to see those fail. I don't think my patch to enable ftrace
direct functions is upstream yet ;)
>>> [n] Generic dynamic event - add/remove kprobe events [PASS]
>>> [n] Generic dynamic event - add/remove synthetic events [PASS]
>>> [n] Generic dynamic event - selective clear (compatibility) [PASS]
>>> @@ -16,10 +16,10 @@
>>> [n] event tracing - enable/disable with event level files [PASS]
>>> [n] event tracing - restricts events based on pid notrace filtering [PASS]
>>> [n] event tracing - restricts events based on pid [PASS]
>>> -[n] event tracing - enable/disable with subsystem level files [PASS]
>>> +[n] event tracing - enable/disable with subsystem level files [FAIL]
>>> [n] event tracing - enable/disable with top level files [PASS]
>>> -[n] Test trace_printk from module [UNRESOLVED]
>>> -[n] ftrace - function graph filters with stack tracer [PASS]
>>> +[n] Test trace_printk from module [FAIL]
>>> +[n] ftrace - function graph filters with stack tracer [FAIL]
>>> [n] ftrace - function graph filters [PASS]
>>> [n] ftrace - function trace with cpumask [PASS]
>>> [n] ftrace - test for function event triggers [PASS]
>>> @@ -27,7 +27,7 @@
>>> [n] ftrace - function pid notrace filters [PASS]
>>> [n] ftrace - function pid filters [PASS]
>>> [n] ftrace - stacktrace filter command [PASS]
>>> -[n] ftrace - function trace on module [UNRESOLVED]
>>> +[n] ftrace - function trace on module [FAIL]
>>> [n] ftrace - function profiler with function tracing [PASS]
>>> [n] ftrace - function profiling [PASS]
>>> [n] ftrace - test reading of set_ftrace_filter [PASS]
>>> @@ -44,10 +44,10 @@
>>> [n] Kprobe event argument syntax [PASS]
>>> [n] Kprobe dynamic event with arguments [PASS]
>>> [n] Kprobes event arguments with types [PASS]
>>> -[n] Kprobe event user-memory access [UNSUPPORTED]
>>> +[n] Kprobe event user-memory access [FAIL]
>>> [n] Kprobe event auto/manual naming [PASS]
>>> [n] Kprobe dynamic event with function tracer [PASS]
>>> -[n] Kprobe dynamic event - probing module [UNRESOLVED]
>>> +[n] Kprobe dynamic event - probing module [FAIL]
>>> [n] Create/delete multiprobe on kprobe event [PASS]
>>> [n] Kprobe event parser error log check [PASS]
>>> [n] Kretprobe dynamic event with arguments [PASS]
>>> @@ -57,11 +57,11 @@
>>> [n] Kprobe events - probe points [PASS]
>>> [n] Kprobe dynamic event - adding and removing [PASS]
>>> [n] Uprobe event parser error log check [PASS]
>>> -[n] test for the preemptirqsoff tracer [UNSUPPORTED]
>>> -[n] Meta-selftest: Checkbashisms [UNRESOLVED]
>>> +[n] test for the preemptirqsoff tracer [FAIL]
>>> +[n] Meta-selftest: Checkbashisms [FAIL]
>>> [n] Test wakeup RT tracer [PASS]
>>> [n] Test wakeup tracer [PASS]
>>> -[n] event trigger - test inter-event histogram trigger expected fail actions [XFAIL]
>>> +[n] event trigger - test inter-event histogram trigger expected fail actions [FAIL]
>>> [n] event trigger - test field variable support [PASS]
>>> [n] event trigger - test inter-event combined histogram trigger [PASS]
>>> [n] event trigger - test multiple actions on hist trigger [PASS]
>>> @@ -96,7 +96,8 @@
>>> [n] (instance) event tracing - enable/disable with event level files [PASS]
>>> [n] (instance) event tracing - restricts events based on pid notrace filtering [PASS]
>>> [n] (instance) event tracing - restricts events based on pid [PASS]
>>> -[n] (instance) event tracing - enable/disable with subsystem level files [PASS]
>>> +[n] (instance) event tracing - enable/disable with subsystem level files [FAIL]
>>> +rmdir: failed to remove '/sys/kernel/tracing/instances/ftracetest.mceByV': Device or resource busy
>>> [n] (instance) ftrace - test for function event triggers [PASS]
>>> [n] (instance) ftrace - function pid notrace filters [PASS]
>>> [n] (instance) ftrace - function pid filters [PASS]
>>>
>>> I needed to add a test timeout to get this far because
>>> "event tracing - enable/disable with subsystem level files" gets stuck.
Does that test pass on LE for you? In the past, I have seen some lockups
but will have to go revisit the tests...
>>
>> There is some regression from mprofile on BE ABIv2
>>
>> --- ftraceBEv2.txt 2021-05-03 18:11:01.100000000 +0200
>> +++ ftraceBE.mprofile.txt 2021-05-03 11:27:24.770000000 +0200
>> @@ -19,7 +19,7 @@
>> [n] event tracing - enable/disable with subsystem level files [FAIL]
>> [n] event tracing - enable/disable with top level files [PASS]
>> [n] Test trace_printk from module [FAIL]
>> -[n] ftrace - function graph filters with stack tracer [PASS]
>> +[n] ftrace - function graph filters with stack tracer [FAIL]
>> [n] ftrace - function graph filters [PASS]
>> [n] ftrace - function trace with cpumask [PASS]
>> [n] ftrace - test for function event triggers [PASS]
>> @@ -31,7 +31,7 @@
>> [n] ftrace - function profiler with function tracing [PASS]
>> [n] ftrace - function profiling [PASS]
>> [n] ftrace - test reading of set_ftrace_filter [PASS]
>> -[n] ftrace - Max stack tracer [PASS]
>> +[n] ftrace - Max stack tracer [FAIL]
>> [n] ftrace - test for function traceon/off triggers [PASS]
>> [n] ftrace - test tracing error log support [PASS]
>> [n] Test creation and deletion of trace instances while setting an event [PASS]
>
> Hmm, I don't see an obvious case where the stack layout is based on
> BE when it should be using ELF ABI version, or ftrace_64_mprofile.S
> depends on LE. +Naveen
Yes, I don't think we ever enabled the stack tracer to work properly on
LE and -mprofile-kernel. I will take a look tomorrow.
- Naveen
^ permalink raw reply
* [powerpc:next-test 7/8] arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer type 'enum stf_barrier_type' from 'void *'
From: kernel test robot @ 2021-05-04 17:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: clang-built-linux, kbuild-all, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: 682ebb015052696ac93cf8df28142d83be8dbcc3 [7/8] powerpc/64s: Fix crashes when toggling stf barrier
config: powerpc-randconfig-r022-20210503 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=682ebb015052696ac93cf8df28142d83be8dbcc3
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 682ebb015052696ac93cf8df28142d83be8dbcc3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> arch/powerpc/lib/feature-fixups.c:233:32: error: cast to smaller integer type 'enum stf_barrier_type' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
enum stf_barrier_type types = (enum stf_barrier_type)data;
^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
vim +233 arch/powerpc/lib/feature-fixups.c
230
231 static int __do_stf_barrier_fixups(void *data)
232 {
> 233 enum stf_barrier_type types = (enum stf_barrier_type)data;
234
235 do_stf_entry_barrier_fixups(types);
236 do_stf_exit_barrier_fixups(types);
237
238 return 0;
239 }
240
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37797 bytes --]
^ permalink raw reply
* Re: remove the nvlink2 pci_vfio subdriver v2
From: Daniel Vetter @ 2021-05-04 16:30 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: qemu-devel, kvm, David Airlie, Greg Kurz, dri-devel, linux-kernel,
Alex Williamson, Paul Mackerras, Greg Kroah-Hartman, qemu-ppc,
linux-api, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20210504155327.GA94750@nvidia.com>
On Tue, May 04, 2021 at 12:53:27PM -0300, Jason Gunthorpe wrote:
> On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:
>
> > Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> > Imo it's best to keep the uapi headers as-is, but exchange the
> > documentation with a big "this is removed, never use again" warning:
>
> We in RDMA have been doing the opposite, the uapi headers are supposed
> to reflect the current kernel. This helps make the kernel
> understandable.
>
> When userspace needs backwards compat to ABI that the current kernel
> doesn't support then userspace has distinct copies of that information
> in some compat location. It has happened a few times over the last 15
> years.
>
> We keep full copies of the current kernel headers in the userspace
> source tree, when the kernel headers change in a compile incompatible
> way we fix everything while updating to the new kernel headers.
Yeah we do the same since forever (it's either from libdrm package, or
directly in the corresponding userspace header). So largely include/uapi
is for documentation
> > - it's good to know which uapi numbers (like parameter extensions or
> > whatever they are in this case) are defacto reserved, because there are
> > binaries (qemu in this) that have code acting on them out there.
>
> Numbers and things get marked reserved or the like
>
> > Anyway feel free to ignore since this might be different than drivers/gpu.
>
> AFAIK drives/gpu has a lot wider userspace, rdma manages this OK
> because we only have one library package that provides the user/kernel
> interface.
But since we have some many projects we've started asking all the userspace
projects to directly take the kernel ones (after the make step to filter
them) so that there's only one source of truth. And also to make sure they
don't merge stuff before the kernel side is reviewed&landed. Which also
means we can't ditch anything userspace might still need on older trees
and stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/pseries: warn if recursing into the hcall tracing code
From: Naveen N. Rao @ 2021-05-04 16:18 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <1620124973.i3ngst0czr.astroid@bobo.none>
Nicholas Piggin wrote:
> Excerpts from Naveen N. Rao's message of May 4, 2021 8:25 pm:
>> Nicholas Piggin wrote:
>>> Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
>>>> Nicholas Piggin wrote:
>>>>> + *
>>>>> + * H_CONFER from spin locks must be treated separately though and use _notrace
>>>>> + * plpar_hcall variants, see yield_to_preempted().
>>>>> */
>>>>> static DEFINE_PER_CPU(unsigned int, hcall_trace_depth);
>>>>>
>>>>> @@ -1843,7 +1846,7 @@ notrace void __trace_hcall_entry(unsigned long opcode, unsigned long *args)
>>>>>
>>>>> depth = this_cpu_ptr(&hcall_trace_depth);
>>>>>
>>>>> - if (*depth)
>>>>> + if (WARN_ON_ONCE(*depth))
>>>>> goto out;
>>>>
>>>> I don't think this will be helpful. The hcall trace depth tracking is
>>>> for the tracepoint and I suspect that this warning will be triggered
>>>> quite easily. Since we have recursion protection, I don't think we
>>>> should warn here.
>>>
>>> What would trigger recursion?
>>
>> The trace code that this protects: trace_hcall_entry(). The tracing code
>> itself can end up doing a hcall as we see in the first patch in this
>> series:
>> plpar_hcall_norets_trace+0x34/0x8c (unreliable)
>> __pv_queued_spin_lock_slowpath+0x684/0x710
>> trace_clock_global+0x148/0x150
>> ring_buffer_lock_reserve+0x12c/0x630
>> trace_event_buffer_lock_reserve+0x80/0x220
>> trace_event_buffer_reserve+0x7c/0xd0
>> trace_event_raw_event_hcall_entry+0x68/0x150
>> __trace_hcall_entry+0x160/0x180
>>
>>
>> There is also a comment aroung hcall_trace_depth that mentions this:
>>
>> /*
>> * Since the tracing code might execute hcalls we need to guard against
>> * recursion. One example of this are spinlocks calling H_YIELD on
>> * shared processor partitions.
>> */
>
> Right but since fixing those, my thought is we better not cause more
> any recursion, so we should fix anything that does.
Ah ok, I got confused by the reference to recursion, since the current
fix did not involve hcall trace recursion per se.
Yes, with the current patch set, we have ensured that at least the
qspinlock code doesn't invoke tracing if it has to do H_CONFER hcall. I
am not entirely sure if that's the only hcall that could be invoked by
the tracing code.
The reason I felt that this warning isn't useful is because it can be
triggered by the perf NMI -- if the perf NMI happens while we are
tracing a different hcall.
Thanks,
Naveen
^ permalink raw reply
* Re: [PATCH] vfio/pci: Revert nvlink removal uAPI breakage
From: Greg Kurz @ 2021-05-04 16:11 UTC (permalink / raw)
To: Alex Williamson
Cc: kvm, gregkh, linux-kernel, qemu-devel, qemu-ppc, daniel,
linux-api, linuxppc-dev, hch
In-Reply-To: <162014341432.3807030.11054087109120670135.stgit@omen>
On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
>
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz <groug@kaod.org>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>
> Greg (Kurz), please double check this resolves the issue. Thanks!
>
It does. Feel free to add:
Reviewed-by: Greg Kurz <groug@kaod.org>
and
Tested-by: Greg Kurz <groug@kaod.org>
Thanks for the quick fix.
Cheers,
--
Greg
> include/uapi/linux/vfio.h | 46 +++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 34b1f53a3901..ef33ea002b0b 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -333,10 +333,21 @@ struct vfio_region_info_cap_type {
> #define VFIO_REGION_SUBTYPE_INTEL_IGD_LPC_CFG (3)
>
> /* 10de vendor PCI sub-types */
> -/* subtype 1 was VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM, don't use */
> +/*
> + * NVIDIA GPU NVlink2 RAM is coherent RAM mapped onto the host address space.
> + *
> + * Deprecated, region no longer provided
> + */
> +#define VFIO_REGION_SUBTYPE_NVIDIA_NVLINK2_RAM (1)
>
> /* 1014 vendor PCI sub-types */
> -/* subtype 1 was VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD, don't use */
> +/*
> + * IBM NPU NVlink2 ATSD (Address Translation Shootdown) register of NPU
> + * to do TLB invalidation on a GPU.
> + *
> + * Deprecated, region no longer provided
> + */
> +#define VFIO_REGION_SUBTYPE_IBM_NVLINK2_ATSD (1)
>
> /* sub-types for VFIO_REGION_TYPE_GFX */
> #define VFIO_REGION_SUBTYPE_GFX_EDID (1)
> @@ -630,9 +641,36 @@ struct vfio_device_migration_info {
> */
> #define VFIO_REGION_INFO_CAP_MSIX_MAPPABLE 3
>
> -/* subtype 4 was VFIO_REGION_INFO_CAP_NVLINK2_SSATGT, don't use */
> +/*
> + * Capability with compressed real address (aka SSA - small system address)
> + * where GPU RAM is mapped on a system bus. Used by a GPU for DMA routing
> + * and by the userspace to associate a NVLink bridge with a GPU.
> + *
> + * Deprecated, capability no longer provided
> + */
> +#define VFIO_REGION_INFO_CAP_NVLINK2_SSATGT 4
> +
> +struct vfio_region_info_cap_nvlink2_ssatgt {
> + struct vfio_info_cap_header header;
> + __u64 tgt;
> +};
>
> -/* subtype 5 was VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD, don't use */
> +/*
> + * Capability with an NVLink link speed. The value is read by
> + * the NVlink2 bridge driver from the bridge's "ibm,nvlink-speed"
> + * property in the device tree. The value is fixed in the hardware
> + * and failing to provide the correct value results in the link
> + * not working with no indication from the driver why.
> + *
> + * Deprecated, capability no longer provided
> + */
> +#define VFIO_REGION_INFO_CAP_NVLINK2_LNKSPD 5
> +
> +struct vfio_region_info_cap_nvlink2_lnkspd {
> + struct vfio_info_cap_header header;
> + __u32 link_speed;
> + __u32 __pad;
> +};
>
> /**
> * VFIO_DEVICE_GET_IRQ_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 9,
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox