stable inclusion
from stable-v5.10.158
commit 5e3d4a68e2e11dbe561fa7de919ff9c82547a215
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5e3d4a68e2e11dbe561fa7de919ff9c82547a215

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

commit aaa65d17 upstream.

Support for the TSX control MSR is enumerated in MSR_IA32_ARCH_CAPABILITIES.
This is different from how other CPU features are enumerated i.e. via
CPUID. Currently, a call to tsx_ctrl_is_supported() is required for
enumerating the feature. In the absence of a feature bit for TSX control,
any code that relies on checking feature bits directly will not work.

In preparation for adding a feature bit check in MSR save/restore
during suspend/resume, set a new feature bit X86_FEATURE_TSX_CTRL when
MSR_IA32_TSX_CTRL is present.

  [ bp: Remove tsx_ctrl_is_supported()]

  [Pawan: Resolved conflicts in backport; Removed parts of commit message
          referring to removed function tsx_ctrl_is_supported()]
Suggested-by: NAndrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NDave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/de619764e1d98afbb7a5fa58424f1278ede37b45.1668539735.git.pawan.kumar.gupta@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

Conflicts:
	arch/x86/include/asm/cpufeatures.h

stable inclusion
from stable-v5.10.158
commit 471fb7b735bf9dd1caf2c8751158b81a3d9a5584
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=471fb7b735bf9dd1caf2c8751158b81a3d9a5584

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

commit 66065157 upstream.

The "force" argument to write_spec_ctrl_current() is currently ambiguous
as it does not guarantee the MSR write. This is due to the optimization
that writes to the MSR happen only when the new value differs from the
cached value.

This is fine in most cases, but breaks for S3 resume when the cached MSR
value gets out of sync with the hardware MSR value due to S3 resetting
it.

When x86_spec_ctrl_current is same as x86_spec_ctrl_base, the MSR write
is skipped. Which results in SPEC_CTRL mitigations not getting restored.

Move the MSR write from write_spec_ctrl_current() to a new function that
unconditionally writes to the MSR. Update the callers accordingly and
rename functions.

  [ bp: Rework a bit. ]

Fixes: caa0ff24 ("x86/bugs: Keep a per-CPU IA32_SPEC_CTRL value")
Suggested-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/806d39b0bfec2fe8f50dc5446dff20f5bb24a959.1669821572.git.pawan.kumar.gupta@linux.intel.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.157
commit 22870431cd250df3eec96753d9422bfc9f0d52a4
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=22870431cd250df3eec96753d9422bfc9f0d52a4

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

commit 4dbd6a3e upstream.

Current code re-calculates the size after aligning the starting and
ending physical addresses on a page boundary. But the re-calculation
also embeds the masking of high order bits that exceed the size of
the physical address space (via PHYSICAL_PAGE_MASK). If the masking
removes any high order bits, the size calculation results in a huge
value that is likely to immediately fail.

Fix this by re-calculating the page-aligned size first. Then mask any
high order bits using PHYSICAL_PAGE_MASK.

Fixes: ffa71f33 ("x86, ioremap: Fix incorrect physical address handling in PAE mode")
Signed-off-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NDave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/1668624097-14884-2-git-send-email-mikelley@microsoft.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.157
commit 3fdeacf087ff92c85162b8a0e111dfe2479238ac
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3fdeacf087ff92c85162b8a0e111dfe2479238ac

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

commit 05311ce9 upstream.

It is valid to receive external interrupt and have broken IDT entry,
which will lead to #GP with exit_int_into that will contain the index of
the IDT entry (e.g any value).

Other exceptions can happen as well, like #NP or #SS
(if stack switch fails).

Thus this warning can be user triggred and has very little value.

Cc: stable@vger.kernel.org
Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221103141351.50662-10-mlevitsk@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.157
commit 7e5cb13091e62b2ad2fe1d3a48753c7219a3e9f9
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59

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

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

commit 917401f2 upstream.

If the VM was terminated while nested, we free the nested state
while the vCPU still is in nested mode.

Soon a warning will be added for this condition.

Cc: stable@vger.kernel.org
Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221103141351.50662-2-mlevitsk@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.156
commit 5e2f14d77223ab7c0bae83f8f2ab3bde6a2bb028
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7MCG1

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5e2f14d77223ab7c0bae83f8f2ab3bde6a2bb028

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

commit ce0d998b upstream.

Deal with errata TGL052, ADL037 and RPL017 "Trace May Contain Incorrect
Data When Configured With Single Range Output Larger Than 4KB" by
disabling single range output whenever larger than 4KB.

Fixes: 67063847 ("perf/x86/intel/pt: Opportunistically use single range output mode")
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221112151508.13768-1-adrian.hunter@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

zhaoxin inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LXCE
CVE: NA

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

There are some issues that need to be resolved for Zhaoxin Platform.
So remove Zhaoxin uncore code first.
Signed-off-by: Nleoliu-oc <leoliu-oc@zhaoxin.com>

stable inclusion
from stable-v5.10.155
commit 154d744fbefcd13648ff036db2d185319afa74dc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7M5F4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=154d744fbefcd13648ff036db2d185319afa74dc

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

commit 2632daeb upstream.

DE_CFG contains the LFENCE serializing bit, restore it on resume too.
This is relevant to older families due to the way how they do S3.

Unify and correct naming while at it.

Fixes: e4d0e84e ("x86/cpu/AMD: Make LFENCE a serializing instruction")
Reported-by: NAndrew Cooper <Andrew.Cooper3@citrix.com>
Reported-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: <stable@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

mainline inclusion
from mainline-v6.3-rc1
commit 5d515ee4
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7H29Y
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d515ee40cb57ea5331998f27df7946a69f14dc3

Intel-SIG: commit 5d515ee4 perf/x86/uncore: Don't WARN_ON_ONCE() for a broken discovery table
Backport SPR MCC UPI uncore discovery warning fixes to OLK-5.10.

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

The kernel warning message is triggered, when SPR MCC is used.

[   17.945331] ------------[ cut here ]------------
[   17.946305] WARNING: CPU: 65 PID: 1 at
arch/x86/events/intel/uncore_discovery.c:184
intel_uncore_has_discovery_tables+0x4c0/0x65c
[   17.946305] Modules linked in:
[   17.946305] CPU: 65 PID: 1 Comm: swapper/0 Not tainted
5.4.17-2136.313.1-X10-2c+ #4

It's caused by the broken discovery table of UPI.

The discovery tables are from hardware. Except for dropping the broken
information, there is nothing Linux can do. Using WARN_ON_ONCE() is
overkilled.

Use the pr_info() to replace WARN_ON_ONCE(), and specify what uncore unit
is dropped and the reason.
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: NMichael Petlan <mpetlan@redhat.com>
Link: https://lore.kernel.org/r/20230112200105.733466-6-kan.liang@linux.intel.comSigned-off-by: NYunying Sun <yunying.sun@intel.com>

mainline inclusion
from mainline-v6.3-rc1
commit 65248a9a
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7H29Y
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65248a9a9ee1ea2e6aad8f35253ffd9096ab81b7

Intel-SIG: commit 65248a9a perf/x86/uncore: Add a quirk for UPI on SPR
Backport SPR MCC UPI uncore discovery warning fixes to OLK-5.10.

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

The discovery table of UPI on some SPR variants, e.g., MCC, is broken.
The third UPI table may includes a wrong address which points to a
non-exists device. The bug impacts both UPI and M3UPI uncore PMON.

Use a pre-defined UPI and M3UPI table to replace the broken table.

Different BIOS may populate a device into a different domain or a
different BUS. The accurate location can only be retrieved at load time.
Add spr_update_device_location() to update the location of the UPI and
M3UPI in the pre-defined table.
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: NMichael Petlan <mpetlan@redhat.com>
Link: https://lore.kernel.org/r/20230112200105.733466-5-kan.liang@linux.intel.comSigned-off-by: NYunying Sun <yunying.sun@intel.com>

mainline inclusion
from mainline-v6.3-rc1
commit bd9514a4
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7H29Y
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd9514a4d5ec25b29728720ca8b3a9ac4e3137d7

Intel-SIG: commit bd9514a4 perf/x86/uncore: Ignore broken units in discovery table
Backport SPR MCC UPI uncore discovery warning fixes to OLK-5.10.

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

Some units in a discovery table may be broken, e.g., UPI of SPR MCC.
A generic method is required to ignore the broken units.

Add uncore_units_ignore in the struct intel_uncore_init_fun, which
indicates the type ID of broken units. It will be assigned by the
platform-specific code later when the platform has a broken discovery
table.
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: NMichael Petlan <mpetlan@redhat.com>
Link: https://lore.kernel.org/r/20230112200105.733466-4-kan.liang@linux.intel.comSigned-off-by: NYunying Sun <yunying.sun@intel.com>

mainline inclusion
from mainline-v6.3-rc1
commit 3af548f2
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7H29Y
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3af548f2361077cd53762c88d62343d4e8ea1efb

Intel-SIG: commit 3af548f2 perf/x86/uncore: Fix potential NULL pointer in uncore_get_alias_name
Backport SPR MCC UPI uncore discovery warning fixes to OLK-5.10.

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

The current code assumes that the discovery table provides valid
box_ids for the normal units. It's not the case anymore since some units
in the discovery table are broken on some SPR variants.

Factor out uncore_get_box_id(). Check the existence of the type->box_ids
before using it. If it's not available, use pmu_idx.
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: NMichael Petlan <mpetlan@redhat.com>
Link: https://lore.kernel.org/r/20230112200105.733466-3-kan.liang@linux.intel.comSigned-off-by: NYunying Sun <yunying.sun@intel.com>

mainline inclusion
from mainline-v6.3-rc1
commit dbf061b2
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I7H29Y
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dbf061b26221fa1a99e6489dd61f5b4ee97a24e8

Intel-SIG: commit dbf061b2 perf/x86/uncore: Factor out uncore_device_to_die()
Backport SPR MCC UPI uncore discovery warning fixes to OLK-5.10.

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

The same code is used to retrieve the logical die ID with a given PCI
device in both the discovery code and the code that supports a system
with > 8 nodes.

Factor out uncore_device_to_die() to replace the duplicate code.

No functional change.
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: NMichael Petlan <mpetlan@redhat.com>
Link: https://lore.kernel.org/r/20230112200105.733466-2-kan.liang@linux.intel.comSigned-off-by: NYunying Sun <yunying.sun@intel.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGGT
CVE: NA

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

Support memcg swap qos by default on x86_64 and arm64 platforms.
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ

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

5a2451f1 ("x86/fpu: Avoid kabi change caused by struct fpu") will
lead to performance degradation of libmicro pthread_create testcase.
Assuming that no 3rd party driver will reach into struct fpu,
replace kabi fix macro from KABI_DEPRECATE to KABI_BROKEN_REMOVE
for element "union fpregs_state state" of struct fpu.
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.162
commit f0a5f0dc0131c6483908601f6e4907befb609c97
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f0a5f0dc0131c6483908601f6e4907befb609c97

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

[ Upstream commit 50b7b6f2 ]

As io_threads are fully set up USER threads it's clearer to separate the
code path from the KTHREAD logic.

The only remaining difference to user space threads is that io_threads
never return to user space again. Instead they loop within the given
worker function.

The fact that they never return to user space means they don't have an
user space thread stack. In order to indicate that to tools like gdb we
reset the stack and instruction pointers to 0.

This allows gdb attach to user space processes using io-uring, which like
means that they have io_threads, without printing worrying message like
this:

  warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386

  warning: Architecture rejected target-supplied description

The output will be something like this:

  (gdb) info threads
    Id   Target Id                  Frame
  * 1    LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
    2    LWP 4864 "iou-mgr-4863"    0x0000000000000000 in ?? ()
    3    LWP 4865 "iou-wrk-4863"    0x0000000000000000 in ?? ()
  (gdb) thread 3
  [Switching to thread 3 (LWP 4865)]
  #0  0x0000000000000000 in ?? ()
  (gdb) bt
  #0  0x0000000000000000 in ?? ()
  Backtrace stopped: Cannot access memory at address 0x0

Fixes: 4727dc20 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD")
Link: https://lore.kernel.org/io-uring/044d0bad-6888-a211-e1d3-159a4aeed52d@polymtl.ca/T/#m1bbf5727e3d4e839603f6ec7ed79c7eebfba6267Signed-off-by: NStefan Metzmacher <metze@samba.org>
cc: Linus Torvalds <torvalds@linux-foundation.org>
cc: Jens Axboe <axboe@kernel.dk>
cc: Andy Lutomirski <luto@kernel.org>
cc: linux-kernel@vger.kernel.org
cc: io-uring@vger.kernel.org
cc: x86@kernel.org
Link: https://lore.kernel.org/r/20210505110310.237537-1-metze@samba.orgReviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>

stable inclusion
from stable-v5.10.162
commit 320c8057eceb18c5d836fcbe0ffb0035fcfe28ff
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=320c8057eceb18c5d836fcbe0ffb0035fcfe28ff

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

PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the
sense that we don't assign ->set_child_tid with our own structure. Just
ensure that every arch sets up the PF_IO_WORKER threads like kthreads
in the arch implementation of copy_thread().
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Conflict:
  arch/s390/kernel/process.c
  arch/x86/kernel/process.c
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O
CVE: NA

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

check_paravirt() calls orc_find() before its implementation code.

If CONFIG_DYNAMIC_FTRACE is enabled, orc_find() will be declared
earlier and compiling will not fail. Otherwise it will fail for
"implicit declaration of function 'orc_find'".

Move declaration of orc_find() out of CONFIG_DYNAMIC_FTRACE macro to
fix this.

Fixes: cbb12ea4718a ("[Huawei] x86/unwind: Fix orc entry for paravirt {save,restore}_fl")
Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O
CVE: NA

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

When CONFIG_PARAVIRT_XXL is enabled, the code of {save,restore}_fl
is defined as:

ff 14 25 00 00 00 00    callq  *0x0

which will be patched to call the xen paravirt function, or native
implementation, in 'paravirt_patch_64.c':

pushfq; popq %rax // for native_save_fl
pushq %rdi; popfq // for native_restore_fl

The orc metadata is generated with insn 'callq', so it can become
inconsistent with the real insn 'push;pop'.
This makes stacktrace on the 'pop' insn fail and incorrect stacktrace
result can be returned.

To prevent reliable stacktrace broken, check the insns when unwind
pt_regs stack frame:

When there are 'push;pop' combination and both insns don't change orc
entry, it means the stack state is inconsistent with orc on pop.
Add one slot to sp_offset for on original orc entry to get the correct
orc entry.
Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>

hulk inclusion
category: bugfix
issue: https://gitee.com/openeuler/kernel/issues/I69VF6

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

If kdump is enabled, when using mce_inject to inject errors, EFI
boot loader would decompress & load second kernel for saving the
vmcore file.

For normal errors that is fine. However, in the MCE case, the panic
CPU that firstly enters into mce_panic() is running within NMI
interrupt context, and the processor blocks delivery of subsequent
NMIs until the next execution of the IRET instruction.

When the panic CPU takes long time in the panic processing route,
and causes the watchdog timeout, at this moment, the processor
already receives NMI interrupt in the background.

In the reproducer sequence below, panic CPU would run into EFI loader
and raise page fault exception (like visiting `vidmem` variable
when attempting to call debug_putstr()), the CPU would execute IRET
instruction when it exits from the page fault handler.

But the loader never registers handler for NMI vector in IDT,
lack of vector handler would cause reboot, which interrupts
kdump procedure and fails to save the vmcore file.

Here is steps to reproduce the above issue (it's sporadic):

  1. # cat uncorrected
     CPU 1 BANK 4
     STATUS uncorrected 0xc0
     MCGSTATUS  EIPV MCIP
     ADDR 0x1234
     RIP 0xdeadbabe
     RAISINGCPU 0
     MCGCAP SER CMCI TES 0x6
  2. # modprobe mce_inject
  3. # mce-inject uncorrected

For increasing the probability of reproduction of this issue, there are
two ways to increase the probability of the bug:

  1. modify the threshold value of watchdog (increase NMI frequency);
  2. and/or add delays before panic() in mce_panic() and modify
     PANIC_TIMEOUT macro;

Fixes: ca0e22d4 ("x86/boot/compressed/64: Always switch to own page table")
Signed-off-by: NZeng Heng <zengheng4@huawei.com>
[ Tidy up changelog, add comments. ]
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230110102745.2514694-1-zengheng4@huawei.com

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BAJ0

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

EulerFS was introduced as a technical preview feature in the 21.09
innovation version. Considering the current discontinuation of Intel
Optane hardware and immature ecosystem, it has been decided to turn it
off in the 22.03 LTS version. It will continue to evolve as an innovative
feature in future innovation versions.
Signed-off-by: NWei Li <liwei391@huawei.com>

GCC inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I734PM

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

This feature add value profile support for kernel by changing GCOV
option "-fprofile-arcs" to "-fprofile-generate" when the new added
config "PGO_KERNEL" is set to y.

Like GCOV, the symbols required by value profile are migrated from
GCC source codes as they cannot be linked to kernel. Specifically,
from libgcc/libgcov-profiler.c to kernel/gcov/gcc_base.c.

kernel options:
CONFIG_PGO_KERNEL=y
Signed-off-by: NXiong Zhou <xiongzhou4@huawei.com>
Reviewed-by: NLi Yancheng <liyancheng@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I737X1

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

Expand qos_level from {-1,0} to [-2, 2], to distinguish the tasks expected
to be with extremely high or low priority level. Using qos_level_weight
to reweight the shares when calculating group's weight. Meanwhile,
set offline task's schedule policy to SCHED_IDLE so that it can be
preempted at check_preempt_wakeup.
Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6V4RY
CVE: NA

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

The NIC driver supports the following features:
Supports IPv4/IPv6 TCP/UDP checksum, TSO, LRO offload and RSS functions.
Supports interrupt aggregation parameter configuration and interrupt
adaptation.
Supports 802.1Q VLAN (Virtual Local Area Network) offloading and
filtering.
Supports NIC SR-IOV (Single Root I/O Virtualization).
Support PF promiscuous mode
Supports VF QinQ mode.
Supports VF link state configuration and QoS configuration.
Support VF MAC address management.
Support VF spoofchk check.
Support port lighting.
Support Ethernet mouth self-negotiation, support pause frame.
Signed-off-by: Nzhoujiadong <zhoujiadong5@huawei.com>
Reviewed-by: NWulike (Collin) <wulike1@huawei.com>

stable inclusion
from stable-v5.10.154
commit e5cef906cb409a7b56641561a715d431b034d1c2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5cef906cb409a7b56641561a715d431b034d1c2

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

commit ad8f9e69 upstream.

Update the emulation mode when handling writes to CR0, because
toggling CR0.PE switches between Real and Protected Mode, and toggling
CR0.PG when EFER.LME=1 switches between Long and Protected Mode.

This is likely a benign bug because there is no writeback of state,
other than the RIP increment, and when toggling CR0.PE, the CPU has
to execute code from a very low memory address.
Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221025124741.228045-14-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit ce9261accccd2a0edffa9b65cd9d23400f71bdfa
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce9261accccd2a0edffa9b65cd9d23400f71bdfa

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

commit d087e0f7 upstream.

Some instructions update the cpu execution mode, which needs to update the
emulation mode.

Extract this code, and make assign_eip_far use it.

assign_eip_far now reads CS, instead of getting it via a parameter,
which is ok, because callers always assign CS to the same value
before calling this function.

No functional change is intended.
Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221025124741.228045-12-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit c8a2fd7a715d9882eed5ddb4105bce2f6a8163c2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c8a2fd7a715d9882eed5ddb4105bce2f6a8163c2

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

commit 5015bb89 upstream.

SYSEXIT is one of the instructions that can change the
processor mode, thus ctxt->mode should be updated after it.

Note that this is likely a benign bug, because the only problematic
mode change is from 32 bit to 64 bit which can lead to truncation of RIP,
and it is not possible to do with sysexit,
since sysexit running in 32 bit mode will be limited to 32 bit version.
Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20221025124741.228045-11-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit e0c7410378cd1adbfd35a65faca5df8936631b1a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0c7410378cd1adbfd35a65faca5df8936631b1a

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

commit 0469e56a upstream.

KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
actually supports. CPUID.80000001:EBX[27:16] are reserved bits and
should be masked off.

Fixes: 07716717 ("KVM: Enhance guest cpuid management")
Signed-off-by: NJim Mattson <jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 9302ebc1c21d93ef7004cd228c8b493dc64f7194
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9302ebc1c21d93ef7004cd228c8b493dc64f7194

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

commit 7030d853 upstream.

KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
actually supports. The following ranges of CPUID.80000008H are reserved
and should be masked off:
    ECX[31:18]
    ECX[11:8]

In addition, the PerfTscSize field at ECX[17:16] should also be zero
because KVM does not set the PERFTSC bit at CPUID.80000001H.ECX[27].

Fixes: 24c82e57 ("KVM: Sanitize cpuid")
Signed-off-by: NJim Mattson <jmattson@google.com>
Message-Id: <20220929225203.2234702-3-jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit cc40c5f3e9211523873c001d34e2f6695d57249b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cc40c5f3e9211523873c001d34e2f6695d57249b

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

commit 079f6889 upstream.

KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
actually supports. In the case of CPUID.8000001AH, only three bits are
currently defined. The 125 reserved bits should be masked off.

Fixes: 24c82e57 ("KVM: Sanitize cpuid")
Signed-off-by: NJim Mattson <jmattson@google.com>
Message-Id: <20220929225203.2234702-4-jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit bd64a88f364cbe2e19b5f55be1cffef2b47bd0a5
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bd64a88f364cbe2e19b5f55be1cffef2b47bd0a5

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

commit eeb69eab upstream.

KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
actually supports. CPUID.80000006H:EDX[17:16] are reserved bits and
should be masked off.

Fixes: 43d05de2 ("KVM: pass through CPUID(0x80000006)")
Signed-off-by: NJim Mattson <jmattson@google.com>
Message-Id: <20220929225203.2234702-2-jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 29d106d086d2f39f8635f402004d1c17a6205583
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=29d106d086d2f39f8635f402004d1c17a6205583

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

commit 6f8faf47 upstream.

The intel_pebs_isolation quirk checks both model number and stepping.
Cooper Lake has a different stepping (11) than the other Skylake Xeon.
It cannot benefit from the optimization in commit 9b545c04
("perf/x86/kvm: Avoid unnecessary work in guest filtering").

Add the stepping of Cooper Lake into the isolation_ucodes[] table.
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221031154550.571663-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 98f6e7c337036dff5a851f557950f5846d3f7d73
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98f6e7c337036dff5a851f557950f5846d3f7d73

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

commit acc5568b upstream.

According to the latest event list, update the MEM_INST_RETIRED events
which support the DataLA facility.

Fixes: 60176089 ("perf/x86/intel: Add Icelake support")
Reported-by: NJannis Klinkenberg <jannis.klinkenberg@rwth-aachen.de>
Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221031154119.571386-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 4dbb739eb29c99c8b59bbb7bbaa71ec1b438f37c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

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

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

[ Upstream commit 1739c701 ]

The KVM_X86_SET_MSR_FILTER ioctls contains a pointer in the passed in
struct which means it has a different struct size depending on whether
it gets called from 32bit or 64bit code.

This patch introduces compat code that converts from the 32bit struct to
its 64bit counterpart which then gets used going forward internally.
With this applied, 32bit QEMU can successfully set MSR bitmaps when
running on 64bit kernels.
Reported-by: NAndrew Randrianasulu <randrianasulu@gmail.com>
Fixes: 1a155254 ("KVM: x86: Introduce MSR filtering")
Signed-off-by: NAlexander Graf <graf@amazon.com>
Message-Id: <20221017184541.2658-4-graf@amazon.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit bb584caee8957469dfd7549dc7accdce806f23dd
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb584caee8957469dfd7549dc7accdce806f23dd

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

[ Upstream commit 2e3272bc ]

In the next patch we want to introduce a second caller to
set_msr_filter() which constructs its own filter list on the stack.
Refactor the original function so it takes it as argument instead of
reading it through copy_from_user().
Signed-off-by: NAlexander Graf <graf@amazon.com>
Message-Id: <20221017184541.2658-3-graf@amazon.com>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 9faacf442d11c872e7e2a66a6d1844459336dfb1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9faacf442d11c872e7e2a66a6d1844459336dfb1

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

[ Upstream commit cf5029d5 ]

The flags for KVM_CAP_X86_USER_SPACE_MSR and KVM_X86_SET_MSR_FILTER
have no protection for their unused bits.  Without protection, future
development for these features will be difficult.  Add the protection
needed to make it possible to extend these features in the future.
Signed-off-by: NAaron Lewis <aaronlewis@google.com>
Message-Id: <20220714161314.1715227-1-aaronlewis@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Stable-dep-of: 2e3272bc ("KVM: x86: Copy filter arg outside kvm_vm_ioctl_set_msr_filter()")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 5bdbccc79c86424fef1960de76abab9e83cfbdc9
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5bdbccc79c86424fef1960de76abab9e83cfbdc9

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

[ Upstream commit 71eac706 ]

Today, core ID is assumed to be unique within each package.

But an AlderLake-N platform adds a Module level between core and package,
Linux excludes the unknown modules bits from the core ID, resulting in
duplicate core ID's.

To keep core ID unique within a package, Linux must include all APIC-ID
bits for known or unknown levels above the core and below the package
in the core ID.

It is important to understand that core ID's have always come directly
from the APIC-ID encoding, which comes from the BIOS. Thus there is no
guarantee that they start at 0, or that they are contiguous.
As such, naively using them for array indexes can be problematic.

[ dhansen: un-known -> unknown ]

Fixes: 7745f03e ("x86/topology: Add CPUID.1F multi-die/package support")
Suggested-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221014090147.1836-5-rui.zhang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 6c31fc028a657e8d53cec5127a39a35cce6dba08
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6c31fc028a657e8d53cec5127a39a35cce6dba08

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

[ Upstream commit 2b12a7a1 ]

CPUID.1F/B does not enumerate Package level explicitly, instead, all the
APIC-ID bits above the enumerated levels are assumed to be package ID
bits.

Current code gets package ID by shifting out all the APIC-ID bits that
Linux supports, rather than shifting out all the APIC-ID bits that
CPUID.1F enumerates. This introduces problems when CPUID.1F enumerates a
level that Linux does not support.

For example, on a single package AlderLake-N, there are 2 Ecore Modules
with 4 atom cores in each module.  Linux does not support the Module
level and interprets the Module ID bits as package ID and erroneously
reports a multi module system as a multi-package system.

Fix this by using APIC-ID bits above all the CPUID.1F enumerated levels
as package ID.

[ dhansen: spelling fix ]

Fixes: 7745f03e ("x86/topology: Add CPUID.1F multi-die/package support")
Suggested-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: NLen Brown <len.brown@intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20221014090147.1836-4-rui.zhang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit f5ad52da145a460b11d3a02a74c995fc33cce2f0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5ad52da145a460b11d3a02a74c995fc33cce2f0

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

[ Upstream commit cb09a379 ]

CPUID Leaf 0x1F defines a DIE_TYPE level (nb: ECX[8:15] level type == 0x5),
but CPUID Leaf 0xB does not. However, detect_extended_topology() will
set struct cpuinfo_x86.cpu_die_id regardless of whether a valid Die ID
was found.

Only set cpu_die_id if a DIE_TYPE level is found. CPU topology code may
use another value for cpu_die_id, e.g. the AMD NodeId on AMD-based
systems. Code ordering should be maintained so that the CPUID Leaf 0x1F
Die ID value will take precedence on systems that may use another value.
Suggested-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201109210659.754018-5-Yazen.Ghannam@amd.com
Stable-dep-of: 2b12a7a1 ("x86/topology: Fix multiple packages shown on a single-package system")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.154
commit 570fa3bcd2f9328efc2123f8c46a50ea6b64b004
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=570fa3bcd2f9328efc2123f8c46a50ea6b64b004

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

[ Upstream commit 5623f751 ]

Add a dedicated "exception type" for #DBs, as #DBs can be fault-like or
trap-like depending the sub-type of #DB, and effectively defer the
decision of what to do with the #DB to the caller.

For the emulator's two calls to exception_type(), treat the #DB as
fault-like, as the emulator handles only code breakpoint and general
detect #DBs, both of which are fault-like.

For event injection, which uses exception_type() to determine whether to
set EFLAGS.RF=1 on the stack, keep the current behavior of not setting
RF=1 for #DBs.  Intel and AMD explicitly state RF isn't set on code #DBs,
so exempting by failing the "== EXCPT_FAULT" check is correct.  The only
other fault-like #DB is General Detect, and despite Intel and AMD both
strongly implying (through omission) that General Detect #DBs should set
RF=1, hardware (multiple generations of both Intel and AMD), in fact does
not.  Through insider knowledge, extreme foresight, sheer dumb luck, or
some combination thereof, KVM correctly handled RF for General Detect #DBs.

Fixes: 38827dbd ("KVM: x86: Do not update EFLAGS on faulting emulation")
Cc: stable@vger.kernel.org
Signed-off-by: NSean Christopherson <seanjc@google.com>
Reviewed-by: NMaxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/r/20220830231614.3580124-9-seanjc@google.comSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>