The TR mode rx flush descriptor did not had a dma_sync_single_for_device()
call to make sure that the DMA see the correct information.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200512134544.5839-1-peter.ujfalusi@ti.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Ludovic Desroches<ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20200507190046.GA15298@embeddedorSigned-off-by: Vinod Koul <vkoul@kernel.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Ludovic Desroches<ludovic.desroches@microchip.com>
Link: https://lore.kernel.org/r/20200507190038.GA15272@embeddedorSigned-off-by: Vinod Koul <vkoul@kernel.org>

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200508210707.GA24136@embeddedorSigned-off-by: Vinod Koul <vkoul@kernel.org>

Fixes coccicheck warnings:

drivers/dma/ti/k3-udma.c:1294:1-3: WARNING: PTR_ERR_OR_ZERO can be used
drivers/dma/ti/k3-udma.c:1311:1-3: WARNING: PTR_ERR_OR_ZERO can be used
drivers/dma/ti/k3-udma.c:1376:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Samuel Zou <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1588757146-38858-1-git-send-email-zou_wei@huawei.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

There is no need to have the 'void __iomem *dma_base_addr' variable
static since new value always be assigned before use it.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200505101353.195446-1-yuehaibing@huawei.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

There is no need to explicitly free memory that have been 'devm_kzalloc'ed.
Simplify the probe function accordingly.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Tested-by: Green Wan <green.wan@sifive.com>
Reviewed-by: Green Wan <green.wan@sifive.com>
Link: https://lore.kernel.org/r/20200501100824.126534-1-christophe.jaillet@wanadoo.frSigned-off-by: Vinod Koul <vkoul@kernel.org>

Fix the following coccicheck warning:

drivers/dma/qcom/hidma.c:553:1-17: WARNING: Assignment of 0/1 to bool
variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Acked By: Sinan Kaya <okaya@kernel.org>
Link: https://lore.kernel.org/r/20200504113406.41530-1-yanaijie@huawei.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Modify dw_edma_device_transfer() to also support the semantics of dma
device transfer for additional use cases involving pcitest utility as a
local initiator.

For its original use case, dw-edma supported the semantics of dma device
transfer from the perspective of a remote initiator who is located across
the PCIe bus from dma channel hardware.

To a remote initiator, DMA_DEV_TO_MEM means using a remote dma WRITE
channel to transfer from remote memory to local memory. A WRITE channel
would be employed on the remote device in order to move the contents of
remote memory to the bus destined for local memory.

To a remote initiator, DMA_MEM_TO_DEV means using a remote dma READ
channel to transfer from local memory to remote memory. A READ channel
would be employed on the remote device in order to move the contents of
local memory to the bus destined for remote memory.

>From the perspective of a local dma initiator who is co-located on the
same side of the PCIe bus as the dma channel hardware, the semantics of
dma device transfer are flipped.

To a local initiator, DMA_DEV_TO_MEM means using a local dma READ channel
to transfer from remote memory to local memory. A READ channel would be
employed on the local device in order to move the contents of remote
memory to the bus destined for local memory.

To a local initiator, DMA_MEM_TO_DEV means using a local dma WRITE channel
to transfer from local memory to remote memory. A WRITE channel would be
employed on the local device in order to move the contents of local memory
to the bus destined for remote memory.

To support local dma initiators, dw_edma_device_transfer() is modified to
now examine the direction field of struct dma_slave_config for the channel
which initiators can configure by calling dmaengine_slave_config().

If direction is configured as either DMA_DEV_TO_MEM or DMA_MEM_TO_DEV,
local initiator semantics are used. If direction is a value other than
DMA_DEV_TO_MEM nor DMA_MEM_TO_DEV, then remote initiator semantics are
used. This should maintain backward compatibility with the original use
case of dw-edma.

The dw-edma-test utility is an example of a remote initiator. From reading
its patch, dw-edma-test does not specifically set the direction field of
struct dma_slave_config. Since dw_edma_device_transfer() also does not
check the direction field of struct dma_slave_config, it seems safe to use
this convention in dw-edma to support both local and remote initiator
semantics.
Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Link: https://lore.kernel.org/r/1588122633-1552-1-git-send-email-alan.mikhak@sifive.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

The validation kernel doc script complains about undescribed
function parameters

.../dmaengine.c:155: warning: Function parameter or member 'dev' not descr ibed in 'dev_to_dma_chan'
.../dmaengine.c:251: warning: cannot understand function prototype: 'dma_cap_mask_t dma_cap_mask_all; '
.../dmaengine.c:257: warning: cannot understand function prototype: 'struct dma_chan_tbl_ent '
.../dmaengine.c:264: warning: cannot understand function prototype: 'struct dma_chan_tbl_ent __percpu *channel_table[DMA_TX_TYPE_END]; '
.../dmaengine.c:304: warning: Function parameter or member 'chan' not described in 'dma_chan_is_local'
.../dmaengine.c:304: warning: Function parameter or member 'cpu' not described in 'dma_chan_is_local'
.../dmaengine.c:414: warning: Function parameter or member 'chan' not described in 'balance_ref_count'
.../dmaengine.c:447: warning: Function parameter or member 'chan' not described in 'dma_chan_get'
.../dmaengine.c:494: warning: Function parameter or member 'chan' not described in 'dma_chan_put'

Add descriptions to the function parameters and in some cases update
existing text as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200429122151.50989-2-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Compiler is not happy about non-static functions due to missed inclusion

.../dmaengine.c:682:18: warning: no previous prototype for ‘dma_get_slave_channel’ [-Wmissing-prototypes]
  682 | struct dma_chan *dma_get_slave_channel(struct dma_chan *chan)
      |                  ^~~~~~~~~~~~~~~~~~~~~
.../dmaengine.c:713:18: warning: no previous prototype for ‘dma_get_any_slave_channel’ [-Wmissing-prototypes]
  713 | struct dma_chan *dma_get_any_slave_channel(struct dma_device *device)
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~~

Include missed header to satisfy compiler.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200429122151.50989-1-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Kernel documentation validator complains that not all members of
struct dmatest_info are being described. Describe them all.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200424161147.16895-6-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Kernel documentation validator complains that not all members of
struct dmatest_params are being described. Describe them all.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200424161147.16895-5-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

The dmatest module parameter 'timeout' is documented as accepting a -1 to mean
"infinite timeout". However, an infinite timeout is not advised, nor possible
since the module parameter is an unsigned int, which won't accept a negative
value. Change the parameter type to be signed integer.

Cc: Gary Hook <Gary.Hook@amd.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200424161147.16895-4-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

This reverts commit ed04b7c5.

While it gives a good description what happens, the approach seems too
confusing. Let's fix it in the following patch.

Cc: Gary Hook <Gary.Hook@amd.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200424161147.16895-3-andriy.shevchenko@linux.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Direct mode or FIFO mode is computed by stm32-dma driver. Add a way for
the user to force direct mode, by setting bit 2 in the bitfield value
specifying DMA features in the device tree.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Link: https://lore.kernel.org/r/20200422102904.1448-3-amelie.delaunay@st.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Direct mode or FIFO mode is computed by stm32-dma driver. Add a way for the
user to force direct mode, by setting bit 2 in the bitfield value
specifying DMA features in the device tree.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Link: https://lore.kernel.org/r/20200422102904.1448-2-amelie.delaunay@st.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

There is no need to call 'hidma_debug_uninit()' in the error handling
path. 'hidma_debug_init()' has not been called yet.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20200427111043.70218-1-christophe.jaillet@wanadoo.frSigned-off-by: Vinod Koul <vkoul@kernel.org>

We only support DMA_DEV_TO_MEM and DMA_MEM_TO_DEV. Let's not do
undefined things with other values and reject them.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200424215020.105281-1-lkundrak@v3.skSigned-off-by: Vinod Koul <vkoul@kernel.org>

Modify dw_edma_irq_request() to check if a struct msi_desc entry exists
before copying the contents of its struct msi_msg pointer.

Without this sanity check, __get_cached_msi_msg() crashes when invoked by
dw_edma_irq_request() running on a Linux-based PCIe endpoint device. MSI
interrupt are not received by PCIe endpoint devices. If irq_get_msi_desc()
returns null, then there is no cached struct msi_msg to be copied.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Link: https://lore.kernel.org/r/1587607101-31914-1-git-send-email-alan.mikhak@sifive.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

completion timeout might trigger unnesesery DMA engine hw reboot
in case of missed issue_pending() .
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com>
Link: https://lore.kernel.org/r/1587589761-32690-3-git-send-email-leonid.ravich@dell.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

removing unnecessary mod_timer from timeout handler
incase of ioat_cleanup_preamble() is true  for cleaner code
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com>
Link: https://lore.kernel.org/r/1587589761-32690-2-git-send-email-leonid.ravich@dell.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

moving duplicate code from timeout error handling to common
function.
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com>
Link: https://lore.kernel.org/r/1587589761-32690-1-git-send-email-leonid.ravich@dell.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

A generic SRAM will driver for Device Tree enabled platforms will do as
well.

The non-DT drivers that use mmp_tdma to transfer audio samples to and from
the audio SRAM should depend on MMP_SRAM themselves.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200419164912.670973-8-lkundrak@v3.skSigned-off-by: Vinod Koul <vkoul@kernel.org>

This makes dma_get_slave_caps() work with the device so that it could
actually be used with soc-generic-dmaengine-pcm.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200419164912.670973-7-lkundrak@v3.skSigned-off-by: Vinod Koul <vkoul@kernel.org>

Let's log an error if the channel can't be prepared because it is in an
unexpected state.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200419164912.670973-6-lkundrak@v3.skSigned-off-by: Vinod Koul <vkoul@kernel.org>

Drop a redundant "mmp_tdma:" from some error messages. The dev_err()
appends mostly the same thing for us:

  [  120.756530] mmp-tdma d42a0800.adma: mmp_tdma: unknown burst size.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200419164912.670973-3-lkundrak@v3.skSigned-off-by: Vinod Koul <vkoul@kernel.org>

requreing kmalloc of 2M high chance to fail in
fragmented memory.
IOAT ring requires 64k * 64B memory
which will be achived by 512k * 8 allocation
instead of 2M * 2.
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com>
Link: https://lore.kernel.org/r/20200416170628.16196-2-leonid.ravich@dell.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

changing macros which assumption is chunk size of 2M,
which can be other size
prepare for changing allocation chunk size.
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Leonid Ravich <Leonid.Ravich@emc.com>
Link: https://lore.kernel.org/r/20200416170628.16196-1-leonid.ravich@dell.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

According to https://www.analog.com/, the company name is spelled
"Analog Devices".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20200416103058.15269-3-geert+renesas@glider.be
[vkoul: make subsystem name dmaengine]
Signed-off-by: Vinod Koul <vkoul@kernel.org>

Convert Renesas R-Car USB-DMA Controller bindings documentation
to json-schema.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1587110829-26609-3-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Convert Renesas R-Car and RZ/G DMA Controller bindings
documentation to json-schema.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/1587110829-26609-2-git-send-email-yoshihiro.shimoda.uh@renesas.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Decouple dw-edma-core.c from struct pci_dev as a step toward integration
of dw-edma with pci-epf-test so the latter can initiate dma operations
locally from the endpoint side. A barrier to such integration is the
dependency of dw_edma_probe() and other functions in dw-edma-core.c on
struct pci_dev.

The Synopsys DesignWare dw-edma driver was designed to run on host side
of PCIe link to initiate DMA operations remotely using eDMA channels of
PCIe controller on the endpoint side. This can be inferred from seeing
that dw-edma uses struct pci_dev and accesses hardware registers of dma
channels across the bus using BAR0 and BAR2.

The ops field of struct dw_edma in dw-edma-core.h is currenty undefined:

const struct dw_edma_core_ops   *ops;

However, the kernel builds without failure even when dw-edma driver is
enabled. Instead of removing the currently undefined and usued ops field,
define struct dw_edma_core_ops and use the ops field to decouple
dw-edma-core.c from struct pci_dev.
Signed-off-by: Alan Mikhak <alan.mikhak@sifive.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Link: https://lore.kernel.org/r/1586971629-30196-1-git-send-email-alan.mikhak@sifive.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Some user apps would like to know the hardware version in order to
determine the variation of the hardware. Export the hardware version number
to userspace via sysfs.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/158696714008.39484.13401950732606906479.stgit@djiang5-desk3.ch.intel.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

Trace of a test for DMA memcpy domains slipped into the glue layer commit.
The memcpy support should be disabled on the MCU UDMAP.

Fixes: d7024191 ("dmaengine: ti: k3-udma: Add glue layer for non DMAengine users")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200327144228.11101-1-peter.ujfalusi@ti.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

It is not possible to compile test the UDMA stack right now due to
dependencies to T_SCI_PROTOCOL and TI_SCI_INTA_IRQCHIP and their
dependencies.

Remove the COMPILE_TEST until it is actually possible to compile test the
drivers.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20200403141950.9359-1-peter.ujfalusi@ti.comSigned-off-by: Vinod Koul <vkoul@kernel.org>

This sorts the actual field names too, potentially causing even more
chaos and confusion at merge time if you have edited the MAINTAINERS
file.  But the end result is a more consistent layout, and hopefully
it's a one-time pain minimized by doing this just before the -rc1
release.

This was entirely scripted:

  ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order
Requested-by: Joe Perches <joe@perches.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

They are all supposed to be sorted, but people who add new entries don't
always know the alphabet.  Plus sometimes the entry names get edited,
and people don't then re-order the entry.

Let's see how painful this will be for merging purposes (the MAINTAINERS
file is often edited in various different trees), but Joe claims there's
relatively few patches in -next that touch this, and doing it just
before -rc1 is likely the best time.  Fingers crossed.

This was scripted with

  /scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS

but then I also ended up manually upper-casing a few entry names that
stood out when looking at the end result.
Requested-by: Joe Perches <joe@perches.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull x86 fixes from Thomas Gleixner:
 "A set of three patches to fix the fallout of the newly added split
  lock detection feature.

  It addressed the case where a KVM guest triggers a split lock #AC and
  KVM reinjects it into the guest which is not prepared to handle it.

  Add proper sanity checks which prevent the unconditional injection
  into the guest and handles the #AC on the host side in the same way as
  user space detections are handled. Depending on the detection mode it
  either warns and disables detection for the task or kills the task if
  the mode is set to fatal"

* tag 'x86-urgent-2020-04-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest
  KVM: x86: Emulate split-lock access as a write in emulator
  x86/split_lock: Provide handle_guest_split_lock()