e1000e: allow turning s0ix flows on for systems with ME
S0ix for GBE flows are needed for allowing the system to get into deepest
power state, but these require coordination of components outside of
control of Linux kernel. For systems that have confirmed to coordinate
this properly, allow turning on the s0ix flows at load time or runtime.
Fixes: e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
Signed-off-by: Mario Limonciello <email address hidden>
(cherry picked from
0001-e1000e-allow-turning-s0ix-flows-on-for-systems-with-.patch)
Signed-off-by: You-Sheng Yang <email address hidden>
The CONFIG_PM_SLEEP #ifdef checks in this file are inconsistent,
leading to a warning about sometimes unused function:
drivers/net/ethernet/intel/e1000e/netdev.c:137:13: error: unused function 'e1000e_check_me' [-Werror,-Wunused-function]
Rather than adding more #ifdefs, just remove them completely
and mark the PM functions as __maybe_unused to let the compiler
work it out on it own.
Fixes: e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
Signed-off-by: Arnd Bergmann <email address hidden>
Tested-by: Aaron Brown <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit 880e6269fd6e60249c8f5f1b98295e9f7e56636d)
Signed-off-by: You-Sheng Yang <email address hidden>
8397a05...
by
Vitaly Lifshits <email address hidden>
e1000e: disable s0ix entry and exit flows for ME systems
Since ME systems do not support SLP_S0 in S0ix state, and S0ix entry
and exit flows may cause errors on them it is best to avoid using
e1000e_s0ix_entry_flow and e1000e_s0ix_exit_flow functions.
This was done by creating a struct of all devices that comes with ME
and by checking if the current device has ME.
Signed-off-by: Vitaly Lifshits <email address hidden>
Tested-by: Aaron Brown <email address hidden>
Signed-off-by: Jeff Kirsher <email address hidden>
(cherry picked from commit e086ba2fccda4c196b84a167493f67f089d0ebdc)
Signed-off-by: You-Sheng Yang <email address hidden>
Some platforms have an AHCI controller behind VMD. These platforms are
working correctly except for a case when the AHCI MSI is programmed with
VMD IRQ vector 0 (0xfee00000). When programmed with any other interrupt
(0xfeeNN000), the MSI is routed correctly and is handled by VMD. Placing
the AHCI MSI(s) in the fast-interrupt allow list solves the issue.
This also requires that VMD allocate more than one MSI/X vector and
changes the minimum MSI/X vectors allocated to two.
Signed-off-by: Jon Derrick <email address hidden>
(cherry-picked from https://patchwork.kernel.org/patch/11758345/)
Signed-off-by: You-Sheng Yang <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
It's not needed to set driver to NULL in mei_cl_device_remove()
which is bus_type remove() handler as this is done anyway
in __device_release_driver().
Actually this is causing an endless loop in driver_detach()
on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module.
The reason list_empty(&drv->p->klist_devices.k_list) is always not-empty.
as the check is always true in __device_release_driver()
if (dev->driver != drv)
return;
The non upstream patch is causing this behavior, titled:
'vfio -- release device lock before userspace requests'
Nevertheless the fix is correct also for the upstream.
Link: https://patchwork.<email address hidden>/
Cc: <email address hidden>
Cc: Andy Whitcroft <email address hidden>
Signed-off-by: Alexander Usyskin <email address hidden>
Signed-off-by: Tomas Winkler <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from commit e852c2c251ed9c23ae6e3efebc5ec49adb504207)
Signed-off-by: Aaron Ma <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
Signed-off-by: Alberto Milone <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
895dd0b...
by
Alex Williamson <email address hidden>
vfio-pci: Invalidate mmaps and block MMIO access on disabled memory
Accessing the disabled memory space of a PCI device would typically
result in a master abort response on conventional PCI, or an
unsupported request on PCI express. The user would generally see
these as a -1 response for the read return data and the write would be
silently discarded, possibly with an uncorrected, non-fatal AER error
triggered on the host. Some systems however take it upon themselves
to bring down the entire system when they see something that might
indicate a loss of data, such as this discarded write to a disabled
memory space.
To avoid this, we want to try to block the user from accessing memory
spaces while they're disabled. We start with a semaphore around the
memory enable bit, where writers modify the memory enable state and
must be serialized, while readers make use of the memory region and
can access in parallel. Writers include both direct manipulation via
the command register, as well as any reset path where the internal
mechanics of the reset may both explicitly and implicitly disable
memory access, and manipulation of the MSI-X configuration, where the
MSI-X vector table resides in MMIO space of the device. Readers
include the read and write file ops to access the vfio device fd
offsets as well as memory mapped access. In the latter case, we make
use of our new vma list support to zap, or invalidate, those memory
mappings in order to force them to be faulted back in on access.
Our semaphore usage will stall user access to MMIO spaces across
internal operations like reset, but the user might experience new
behavior when trying to access the MMIO space while disabled via the
PCI command register. Access via read or write while disabled will
return -EIO and access via memory maps will result in a SIGBUS. This
is expected to be compatible with known use cases and potentially
provides better error handling capabilities than present in the
hardware, while avoiding the more readily accessible and severe
platform error responses that might otherwise occur.
Fixes: CVE-2020-12888
Reviewed-by: Peter Xu <email address hidden>
Signed-off-by: Alex Williamson <email address hidden>
(cherry picked from commit abafbc551fddede3e0a08dee1dcde08fc0eb8476)
CVE-2020-12888
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>
