mainline inclusion
from mainline-v5.17
commit 39150352
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

asm/svm.h is the correct place for all values that are defined in
the SVM spec, and that includes AVIC.

Also add some values from the spec that were not defined before
and will be soon useful.
Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20220207155447.840194-10-mlevitsk@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 43e540cc
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

When the 5-level page table is enabled on host OS, the nested page table
for guest VMs must use 5-level as well. Update get_npt_level() function
to reflect this requirement. In the meanwhile, remove the code that
prevents kvm-amd driver from being loaded when 5-level page table is
detected.
Signed-off-by: NWei Huang <wei.huang2@amd.com>
Message-Id: <20210818165549.3771014-4-wei.huang2@amd.com>
[Tweak condition as suggested by Sean. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.13
commit 03ca4589
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Disallow loading KVM SVM if 5-level paging is supported.  In theory, NPT
for L1 should simply work, but there unknowns with respect to how the
guest's MAXPHYADDR will be handled by hardware.

Nested NPT is more problematic, as running an L1 VMM that is using
2-level page tables requires stacking single-entry PDP and PML4 tables in
KVM's NPT for L2, as there are no equivalent entries in L1's NPT to
shadow.  Barring hardware magic, for 5-level paging, KVM would need stack
another layer to handle PML5.

Opportunistically rename the lm_root pointer, which is used for the
aforementioned stacking when shadowing 2-level L1 NPT, to pml4_root to
call out that it's specifically for PML4.
Suggested-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Message-Id: <20210505204221.1934471-1-seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit 91f75eb4
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

AMD systems currently lay out MCA bank types such that the type of bank
number "i" is either the same across all CPUs or is Reserved/Read-as-Zero.

For example:

  Bank # | CPUx | CPUy
    0      LS     LS
    1      RAZ    UMC
    2      CS     CS
    3      SMU    RAZ

Future AMD systems will lay out MCA bank types such that the type of
bank number "i" may be different across CPUs.

For example:

  Bank # | CPUx | CPUy
    0      LS     LS
    1      RAZ    UMC
    2      CS     NBIO
    3      SMU    RAZ

Change the structures that cache MCA bank types to be per-CPU and update
smca_get_bank_type() to handle this change.

Move some SMCA-specific structures to amd.c from mce.h, since they no
longer need to be global.

Break out the "count" for bank types from struct smca_hwid, since this
should provide a per-CPU count rather than a system-wide count.

Apply the "const" qualifier to the struct smca_hwid_mcatypes array. The
values in this array should not change at runtime.
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211216162905.4132657-3-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit 0b746e8c
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

The address translation code used for current AMD systems is
non-architectural. So move it to EDAC.
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20211028175728.121452-2-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.16
commit f38ce910
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Export smca_get_bank_type for use in the AMD GPU
driver to determine MCA bank while handling correctable
and uncorrectable errors in GPU UMC.
Signed-off-by: NMukul Joshi <mukul.joshi@amd.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit 5176a93a
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add HWID and McaType values for new SMCA bank types, and add their error
descriptions to edac_mce_amd.

The "PHY" bank types all have the same error descriptions, and the NBIF
and SHUB bank types have the same error descriptions. So reuse the same
arrays where appropriate.

  [ bp: Remove useless comments over hwid types. ]
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211216162905.4132657-2-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.14
commit 94a311ce
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add the (HWID, MCATYPE) tuples and names for new SMCA bank types.

Also, add their respective error descriptions to the MCE decoding module
edac_mce_amd. Also while at it, optimize the string names for some SMCA
banks.

 [ bp: Drop repeated comments, explain why UMC_V2 is a separate entry. ]
Signed-off-by: NMuralidhara M K <muralimk@amd.com>
Signed-off-by: NNaveen Krishna Chatradhi  <nchatrad@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NYazen Ghannam <yazen.ghannam@amd.com>
Link: https://lkml.kernel.org/r/20210526164601.66228-1-nchatrad@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.18
commit 2151c84e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Introduce a "family flags" bitmask that can be used to indicate any
special behavior needed on a per-family basis.

Add a flag to indicate a system uses the new register offsets introduced
with Family 19h Model 10h.

Use this flag to account for register offset changes, a new bitfield
indicating DDR5 use on a memory controller, and to set the proper number
of chip select masks.

Rework f17_addr_mask_to_cs_size() to properly handle the change in chip
select masks. And update code comments to reflect the updated Chip
Select, DIMM, and Mask relationships.

[uninitialized variable warning]
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NWilliam Roche <william.roche@oracle.com>
Link: https://lore.kernel.org/r/20220202144307.2678405-3-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.18
commit 75aeaaf2
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Current AMD systems allow mixing of DIMM types within a system. However,
DIMMs within a channel, i.e. managed by a single Unified Memory
Controller (UMC), must be of the same type.

Handle this possible configuration by checking and setting the memory
type for each individual "UMC" structure.
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NWilliam Roche <william.roche@oracle.com>
Link: https://lore.kernel.org/r/20220202144307.2678405-2-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit e2be5955
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add a new family type for AMD Family 19h Models 10h to 1Fh. Use this new
family type for Models A0h to AFh also.

Increase the maximum number of controllers from 8 to 12.
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211208174356.1997855-3-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit f9571124
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Include Registered-DDR5 and Load-Reduced DDR5 in the list of memory
types.
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211208174356.1997855-2-yazen.ghannam@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit 8bb050cd
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

The current driver can read the temperatures from upto 8 CCDs
(Core-Complex Die).

The newer AMD Family 19h Models 10h-1Fh and A0h-AFh can support up to
12 CCDs. Update the driver to read up to 12 CCDs.
Signed-off-by: NBabu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163776976762.904164.5618896687524494215.stgit@bmoger-ubuntuSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit 3cf90efa
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add thermal info support for AMD Family 19h Models 10h-1Fh and A0h-AFh.
Thermal info is supported via a new PCI device ID at offset 0x300h.
Signed-off-by: NBabu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163640829419.955062.12539219969781039915.stgit@bmoger-ubuntuSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit 4fb0abfe
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add the new PCI Device IDs to support new generation of AMD 19h family of
processors.
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBabu Moger <babu.moger@amd.com>
Acked-by: NKrzysztof Wilczyński <kw@linux.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>  # pci_ids.h
Link: https://lore.kernel.org/r/163640828133.955062.18349019796157170473.stgit@bmoger-ubuntuSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.17
commit f707bcb5
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Usage of these definitions were removed after the commit 0a4e668b
("hwmon: (k10temp) Remove support for displaying voltage and current on Zen CPUs").
So, cleanup them up.
Signed-off-by: NBabu Moger <babu.moger@amd.com>
Link: https://lore.kernel.org/r/163640828776.955062.15863375803675701204.stgit@bmoger-ubuntuSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 23c69b90
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Commit id "b00647c4",
adds reporting current and voltage to k10temp.c

The commit id "0a4e668b",
removed reporting current and voltage from k10temp.c

The curr and in(voltage) entries are not removed from
"k10temp_info" structure. Removing those residue entries.
while at it, update k10temp driver documentation
Signed-off-by: Nsuma hegde <suma.hegde@amd.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20210902174155.7365-2-nchatrad@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 25572c81
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Yellow carp matches same behavior as green sardine and other Zen3
products, but have different CCD offsets.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Acked-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20210827201527.24454-3-mario.limonciello@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 0e3f52bb
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Some of the existing assumptions made do not scale properly
to new silicon in upcoming changes.  This commit should cause
no functional changes to existing silicon.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20210827201527.24454-2-mario.limonciello@amd.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 02a2484c
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Tdie is an offset calculation that should only be shown when temp_offset
is actually put into a table.  This is useless to show for all CPU/APU.
Show it only when necessary.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 128066c8
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

These follow the rest of the existing codepaths for families
17h and 19h.
Signed-off-by: NMario Limonciello <mario.limonciello@amd.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 02c9dce4
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add support for Zen3 Ryzen APU.
Signed-off-by: NDavid Bartley <andareed@gmail.com>
Link: https://lore.kernel.org/r/20210517064131.4369-1-andareed@gmail.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.12
commit c8d0d3fa
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

The module has only support for Zen3 server CPUs right now.
Add support for Family 0x19, model 0x21 which are Zen3 Ryzen Desktop CPUs.
Tested on 5800x, 5900x and 5950x CPUs.
Signed-off-by: NGabriel Craciunescu <nix.or.die@gmail.com>
Link: https://lore.kernel.org/r/20201223005315.20077-1-nix.or.die@gmail.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.14
commit 2ade8fc6
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

This is a front patch for later backporting of k10temp driver.

-------------------------------------------------

This is required to support Zen3 APUs in k10temp.
Signed-off-by: NDavid Bartley <andareed@gmail.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NWei Huang <wei.huang2@amd.com>
Link: https://lkml.kernel.org/r/20210520174130.94954-1-andareed@gmail.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15
commit 3438de03
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5NGRU
CVE: NA

-------------------------------------------------

Add a new CCP/PSP PCI device ID and corresponding entry in the dev_vdata
struct.
Signed-off-by: NJohn Allen <john.allen@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

Merge Pull Request from: @zhengzengkai 
 
```
[Description]​
The ROH module driver consists of the ROH Core and ROH DRV
modules, which work with hardware to implement communication
between nodes through HCCS packets.
ROH Core is a protocol stack of the ROH architecture. It provides
related services for upper layers by invoking operation interfaces
provided by the ROH DRV.
The ROH DRV implements the lower layer functions of the ROH
featureand provides a series of interfaces for operating hardware
for the ROH Core. 

This patch adds ROH device driver support, including:
1. ROH Core initialization
2. Provide roh device registration framework.
3. etc

[Testing]
kernel options:
CONFIG_ROH=m

Test passed with below step:
1. load the roh_core.ko
# insmod roh_core.ko
2. There is no error when roh_core.ko is loaded,
confirm that ko is loaded normally:
# lsmod | grep roh_core
roh_core 24576 0 - Live 0xffff800008f07000
3. View the sysfs file and confirm that the roh
directory has been generated:
# ls /sys/class/ | grep roh
roh
4.Uninstall roh_core.ko without any errors
```
 
 
Link:https://gitee.com/openeuler/kernel/pulls/191 
Reviewed-by: Ling Mingqiang <lingmingqiang@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com> 

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5WKYW

-----------------------------------------------------------------------

Add ROH device driver support, include:
1. roh core initialization
2. provide a registration framework for roh device.
3. etc.
Signed-off-by: NKe Chen <chenke54@huawei.com>
Reviewed-by: NGang Zhang <gang.zhang@huawei.com>
Reviewed-by: NYefeng Yan <yanyefeng@huawei.com>
Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3

---------------------------------------------------------------------

Log return value of clear_hem() to help diagnose.
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3

---------------------------------------------------------------------

The return value of set_hem has been fixed to ENODEV, which will
lead a diagnostic information missing.

Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver")
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit 4ad81814
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=4ad8181426df92976feee5fbc55236293d069b37

---------------------------------------------------------------------

Due to the discrete nature of the HIP08 timer unit, a requester might
finish the timeout period sooner, in elapsed real time, than its responder
does, even when both sides share the identical RNR timeout length included
in the RNR Nak packet and the responder indeed starts the timing prior to
the requester. Furthermore, if a 'providential' resend packet arrived
before the responder's timeout period expired, the responder is certainly
entitled to drop the packet silently in the light of IB protocol.

To address this problem, our team made good use of certain hardware facts:

1) The timing resolution regards the transmission arrangements is 1
   microsecond, e.g. if cq_period field is set to 3, it would be
   interpreted as 3 microsecond by hardware

2) A QPC field shall inform the hardware how many timing unit (ticks)
   constitutes a full microsecond, which, by default, is 1000

3) It takes 14ns for the processor to handle a packet in the buffer, so
   the RNR timeout length of 10ns would ensure our processing mechanism is
   disabled during the entire timeout period and the packet won't be
   dropped silently

To achieve (3), we permanently set the QPC field mentioned in (2) to zero
which nominally indicates every time tick is equivalent to a microsecond
in wall-clock time; now, a RNR timeout period at face value of 10 would
only last 10 ticks, which is 10ns in wall-clock time.

It's worth noting that we adapt the driver by magnifying certain
configuration parameters(cq_period, eq_period and ack_timeout)by 1000
given the user assumes the configuring timing unit to be microseconds.

Also, this particular improvisation is only deployed on HIP08 since other
hardware has already solved this issue.

Fixes: cfc85f3e ("RDMA/hns: Add profile support for hip08 driver")
Link: https://lore.kernel.org/r/20211209140655.49493-1-liangwenpeng@huawei.comSigned-off-by: NYangyang Li <liyangyang20@huawei.com>
Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.14-rc1
commit 7b0006db
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=7b0006db6800da4c05883584befa46502d85dede

---------------------------------------------------------------------

The base address table is allocated by dma allocator, and the size is
always aligned to PAGE_SIZE. If a fixed size is used to allocate the
table, the number of base address entries stored in the table will be
smaller than that can actually stored.

Link: https://lore.kernel.org/r/1621589395-2435-2-git-send-email-liweihang@huawei.comSigned-off-by: NXi Wang <wangxi11@huawei.com>
Signed-off-by: NWeihang Li <liweihang@huawei.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3

-----------------------------------------------------------

This reverts commit f9d4c848.

This patch is synchronized from the linux mainline, but some important
code is lost during synchronization. This results in a large code
difference between openEuler and the linux mainline.
It is a better option to revert the bad patch and resync a full patch
from the linux mainline. The resynchronized patch is the second patch
in this patchlist.
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

----------------------------------------------------------

The kernel space does not support the rq inline feature anymore,
so remove the code associated with rq inline.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

----------------------------------------------------------

Enable the CQEIE field and configure the CQEIS field of QPC.
And add compatibility handling.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

----------------------------------------------------------

The rq inline makes some changes as follows, Firstly, it is only
used in user space. Secondly, it should notify hardware in QP RTR
status. Thirdly, Add compatibility processing between different
user space and kernel space. Change the HNS_ROCE_CAP_FLAG_RQ_INLINE
to a new bit to prevent old kernel spaces / spaced from enabling
rq inline.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

----------------------------------------------------------

Currently, the driver only uses max_send_sge to initialize sge num
when creating_qp. So, in the sq inline scenario, the driver may not
has enough sge to send data. For example, if max_send_sge is 16 and
max_inline_data is 1024, the driver needs 1024/16=64 sge to send data.
Therefore, the calculation method of sge num is modified to take the
maximum value of max_send_sge and max_inline_data/16 to solve this
problem.

Fixes:05201e01("RDMA/hns: Refactor process of setting extended sge")
Fixes:30b70788("RDMA/hns: Support inline data in extented sge space for RC")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

-----------------------------------------------------------

This reverts commit 34542349.

Fixes: 34542349 ("RDMA/hns: Fix the problem of sge nums")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

-----------------------------------------------------------

This reverts commit d0b40fc5.

Fixes: d0b40fc5 ("RDMA/hns: Remove enable rq inline in kernel and add compatibility handling")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

-----------------------------------------------------------

This reverts commit 5a18385d.

Fixes: 5a18385d ("RDMA/hns: Support cqe inline in user space")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5XJ01

----------------------------------------------------------------------

Add default algorithm processing.

Fixes: f91696f2 ("RDMA/hns: Support congestion control type selection according to the FW")
Signed-off-by: Nzhengfeng luo <luozhengfeng@h-partners.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>