TI AM335x CPPI 4.1 module uses a single register bit for CPPI interrupts
in both musb controllers. So disabling the CPPI irq in one musb driver
breaks the other musb module.
Since musb is already disabled before tearing down dma controller in
musb_remove(), it is safe to not disable CPPI irq in
musb_dma_controller_destroy().
Fixes: 255348289f ("usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS")
Cc: stable@vger.kernel.org
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver
- Make sure of_node_get/put() calls are balanced in the partition
parsing code
- Fix a race in the denali NAND controller driver
- Fix false positive WARN_ON() in the marvell NAND controller driver
-----BEGIN PGP SIGNATURE-----
iQI5BAABCAAjBQJbo2UeHBxib3Jpcy5icmV6aWxsb25AYm9vdGxpbi5jb20ACgkQ
Ze02AX4ItwDWbxAAttHJYM0BsQaBBbso7bjRhk8i3E5/C600W3Lv/MB9LuVjP2xX
sJ0yA+2akvuv5t5ieHgrFZD4gOMdZ/oMRTeXFEy+YxvluJZx6ta1SR5SJqqvJWd8
xTnOteaU/Yw84GqA/bJMy+j4xp/5tqho305NzIB1Jn0XbCTst91n3HxGNIKQioYa
RSGND2bW/UE6p/TRpNQTZu10JWeuCPb9rVD50XL5fAQF+Fdu0ELpfkkPDXTwxLb2
Msdo7wfECNK3Oj22yXtEnPOia5SaBOiOmQ/fP7EiQNMFvfC+heFAbG5J5xZRe2mw
JWUtiCPajLSzJv3qv6kxf4VEbj8cQo9pN4Drfy+FRO7CogXoDpxvXQ5vmX042Q7M
ygt/CNqe0NC8hJPt2eygaAyRIXXHTo45VAd1DWgN3bi2ZEy1DZ8oD0RjhiD8B7Fn
EDcHO019spNglM0J+RqwQPrCWwgnw9ext8xGprwj0K+B78s1HgmGnuMfFE/tdn/w
oZNn1v1iNZxOv5oz/VR9QTt3ggVjOXBzKZGGoXSjI0ScrXrS9WZg1yR6fzf/DeVg
0whIlXQBsvRaMIxeSnXHboK5ZBaOBCficGKS8mxlxue7QHErrPV6RiunFP8nvq5j
yMt5qYCdCRHd2BZlhKO1pX8RtnwK7Sew1E/0USroS/Ke87hoGETiQxLf3ZE=
=p43N
-----END PGP SIGNATURE-----
Merge tag 'mtd/fixes-for-4.19-rc5' of git://git.infradead.org/linux-mtd
Boris writes:
"- Fixes a bug in the ->read/write_reg() implementation of the m25p80
driver
- Make sure of_node_get/put() calls are balanced in the partition
parsing code
- Fix a race in the denali NAND controller driver
- Fix false positive WARN_ON() in the marvell NAND controller driver"
* tag 'mtd/fixes-for-4.19-rc5' of git://git.infradead.org/linux-mtd:
mtd: devices: m25p80: Make sure the buffer passed in op is DMA-able
mtd: partitions: fix unbalanced of_node_get/put()
mtd: rawnand: denali: fix a race condition when DMA is kicked
mtd: rawnand: marvell: prevent harmless warnings
here comes a collection of various fixes, mostly for stable-tree
or regression fixes.
Two relatively high LOCs are about the (rather simple) conversion of
uapi integer types in topology API, and a regression fix about HDMI
hotplug notification on AMD HD-audio. The rest are all small
individual fixes like ASoC Intel Skylake race condition, minor
uninitialized page leak in emu10k1 ioctl, Firewire audio error paths,
and so on.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAluhankOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8hRxAAtMnqlbnld2ihoENWWwDPD1RedUhICP3ItOUB
8t5QXhzLlZ1fHKiDy8XAE7bljdEk8VJJDkva1umGztaAe9vxFzqjIvYn2yYvdX0d
M9qxrJtY8V65Tsq9s1hUYdbONGGveXOabWEa+PwQOQdsIq4O+kwvyOvjWShvcdHQ
vwKyaeC3E3pM0BIwna6O35E7GEEAauNhC/7ejdVNOD53Gn+gD3aREQqmiQvpFpqU
6/uhptM6Pp5Q18WOoKgVyDojPe2kNUDZ3SqMIyX90CDiIzVOvT8arB+19Ne5cnb+
lKItWDaVqzGX+hdG2WwsGNKrxVrAgZpETmeVjlvfyUIH+fcfierpiNuQi++v1hAH
VMHAYUF8ks9wS0FzmEX98PtlkPb2y1AyrcxrhWcZjfItmAFihXu+mE4EIG+4mTk6
JvqewxFegVgQxK3ohwkl5+dv01HV3BJJ/1W5hYq+qmXzRqU0XIrOt9wBOwXJPREo
BDQBbsWNejZYbJYuR3N2b7GCDK3u7wt1KoSfehN3t1ueSqJkq07BHw81RpC1uZ4h
q6DWOfS5XZf+fDSwCabddYzlZwR9R/dFbYC+LogW0eRhMIMga0HSc2sSNNQjBE3I
I7wgiU3NhRt6bGSg3B8/za52TaWD61QigXNmKSxRqgw1l1y+VeMkVoIjgxz9it8j
GWDFG3g=
=Qk/8
-----END PGP SIGNATURE-----
Merge tag 'sound-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Takashi writes:
"sound fixes for 4.19-rc5
here comes a collection of various fixes, mostly for stable-tree
or regression fixes.
Two relatively high LOCs are about the (rather simple) conversion of
uapi integer types in topology API, and a regression fix about HDMI
hotplug notification on AMD HD-audio. The rest are all small
individual fixes like ASoC Intel Skylake race condition, minor
uninitialized page leak in emu10k1 ioctl, Firewire audio error paths,
and so on."
* tag 'sound-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (33 commits)
ALSA: fireworks: fix memory leak of response buffer at error path
ALSA: oxfw: fix memory leak of discovered stream formats at error path
ALSA: oxfw: fix memory leak for model-dependent data at error path
ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path
ALSA: hda - Enable runtime PM only for discrete GPU
ALSA: oxfw: fix memory leak of private data
ALSA: firewire-tascam: fix memory leak of private data
ALSA: firewire-digi00x: fix memory leak of private data
sound: don't call skl_init_chip() to reset intel skl soc
sound: enable interrupt after dma buffer initialization
Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation"
ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO
ASoC: cs4265: fix MMTLR Data switch control
ASoC: AMD: Ensure reset bit is cleared before configuring
ALSA: fireface: fix memory leak in ff400_switch_fetching_mode()
ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping
ASoC: rsnd: don't fallback to PIO mode when -EPROBE_DEFER
ASoC: rsnd: adg: care clock-frequency size
ASoC: uniphier: change status to orphan
ASoC: rsnd: fixup not to call clk_get/set under non-atomic
...
After 2dd4531686 ("kgdboc: Fix restrict error"), kgdboc_option_setup is
now only used when built in, resulting in a warning when compiled as a
module:
drivers/tty/serial/kgdboc.c:134:12: warning: 'kgdboc_option_setup' defined but not used [-Wunused-function]
static int kgdboc_option_setup(char *opt)
^~~~~~~~~~~~~~~~~~~
Move the function under the appropriate ifdef for builtin only.
Fixes: 2dd4531686 ("kgdboc: Fix restrict error")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudarsana Reddy Kalluru says:
====================
qed: Fix series for multi-function mode implementation.
The patch series addresses few issues in the switch dependent multi-function modes.
Please consider applying it to 'net' tree.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support to configure the DORQ to use vlan-id/priority for
roce EDPM.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In certain multi-function switch dependent modes, firmware adds vlan tag 0
to the untagged frames. This leads to double tagging for the traffic
if the dcbx is enabled, which is not the desired behavior. To avoid this,
driver needs to set "dcb_dont_add_vlan0" flag.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In multi-function mode, driver receives the stag value (outer vlan)
for a PF from management FW (MFW). If the stag value is negotiated prior to
the driver load, then the stag is not notified to the driver and hence
driver will have the invalid stag value.
The fix is to request the MFW for STAG value during the driver load time.
Fixes: cac6f691 ("qed: Add support for Unified Fabric Port")
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Tomer Tayar <Tomer.Tayar@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 19be557010 ("drm/ttm: add operation ctx to ttm_bo_validate v2")
introduced a regression where the vmwgfx driver refused to evict a
buffer that was still busy instead of waiting for it to become idle.
Fix this.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If framebuffers are larger, we create bounce surfaces that are within
STDU limits.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
For all display units, limit mode size exposed to texture_max_width/
height as this is the maximum framebuffer size that virtual device can
create.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
For STDU individual screen target size is limited by
SVGA_REG_SCREENTARGET_MAX_WIDTH/HEIGHT registers so add that limit
during atomic check_modeset.
An additional limit is placed in the update_layout ioctl to avoid
requesting layouts that current user-space typically can't support.
Also modified the comments to reflect current limitation on topology.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
During atomic check to prepare the new topology no need to check if
old_crtc_state was enabled or not. This will cause atomic_check to fail
because due to connector routing a crtc can be in atomic_state even if
there was no change to enable status.
Detected this issue with igt run.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
mpe: This was fixed originally in commit d3d4ffaae4
("powerpc/powernv/ioda2: Reduce upper limit for DMA window size"), but
contrary to what the merge commit says was inadvertently lost by me in
commit ce57c6610c ("Merge branch 'topic/ppc-kvm' into next") which
brought in changes that moved the code to a new file. So reapply it to
the new file.
Original commit message follows:
We use PHB in mode1 which uses bit 59 to select a correct DMA window.
However there is mode2 which uses bits 59:55 and allows up to 32 DMA
windows per a PE.
Even though documentation does not clearly specify that, it seems that
the actual hardware does not support bits 59:55 even in mode1, in
other words we can create a window as big as 1<<58 but DMA simply
won't work.
This reduces the upper limit from 59 to 55 bits to let the userspace
know about the hardware limits.
Fixes: ce57c6610c ("Merge branch 'topic/ppc-kvm' into next")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
With CONFIG_DMA_API_DEBUG enabled we now get a warning when using the
mvneta driver:
mvneta d0030000.ethernet: DMA-API: device driver frees DMA memory with
wrong function [device address=0x000000001165b000] [size=4096 bytes]
[mapped as page] [unmapped as single]
This is because when using the s/w buffer management, the Rx descriptor
buffer is mapped with dma_map_page but unmapped with dma_unmap_single.
This patch fixes this by using the right unmapping function.
Fixes: 562e2f467e ("net: mvneta: Improve the buffer allocation method for SWBM")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Avoid ELP information leak, by Sven Eckelmann
- Fix sysfs segfault issues, by Sven Eckelmann (2 patches)
- Fix locking when adding entries in various lists,
by Sven Eckelmann (5 patches)
- Fix refcount if queue_work() fails, by Marek Lindner (2 patches)
- Fixup forgotten version bump, by Sven Eckelmann
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAluiO2gWHHN3QHNpbW9u
d3VuZGVybGljaC5kZQAKCRChK+OYQpKeoRrcD/9F8CZnQusMuvLe/8sxWiyb70zx
Fx8dsZS7ppMN4SoQU5dB9NbgDwzDdK1L42Fgzm2CfgeEIYzUOsw6l/+KFuXQSU/t
Sb/NloyFNQ5nGHO6IcLY8Mqa6bMX/6dlBinRcuTyXOECqqBAaYTf56olNyUty3K6
9BHfyule+oZtQ5aN6DhOsVB0ATxGoqJK2lbAePj+mzb+5253YykUhjAaEVGM0oNN
3ULq34dyPxPb2t/z0qNK8CJ2+RXPrAqssEaD0X0awl7spFJYt4jvAXwKvHnR/ryo
6EDrvnd38bcs+DJrNHhycyk+bITT6njnTv4kJtQuFAd+eap5h7RR5mAElSBgWSAB
Xy0HjwNY/mb/OMY85/o2EjLOrmr31YpJcLWI6sLqPrUbD4WGhoW1ZB71AQCL3nHL
6YLln+mYCK00KT5hPU9MzO/3nGyd3uvRjKLLd42chC+YZXxvhWFFEkpsEGYJZq/q
qduWytS7+W+FSUrDEgTePJh6rdwAbFLSUWqW5bBxA5ATctxxbsslF8IvUJy6fCel
Sp+iNIkjfp+eB8jFaacrrw4At1YE2nDJlyycMvLQvQOaSCtpGuKiTqsqTHFbgSy4
Y7QTHNLLbguiASCuhVvP5EYsBm8ZqNUjXMJZCHOCVaXp/cQ3K7Z6yC2pEst2QJ6m
9lrPOg32Rfo9dRNcTA==
=B1qZ
-----END PGP SIGNATURE-----
Merge tag 'batadv-net-for-davem-20180919' of git://git.open-mesh.org/linux-merge
Simon Wunderlich says:
====================
pull request for net: batman-adv 2018-09-19
here are some bugfixes which we would like to see integrated into net.
We forgot to bump the version number in the last round for net-next, so
the belated patch to do that is included - we hope you can adopt it.
This will most likely create a merge conflict later when merging into
net-next with this rounds net-next patchset, but net-next should keep
the 2018.4 version[1].
[1] resolution:
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -25,11 +25,7 @@
#define BATADV_DRIVER_DEVICE "batman-adv"
#ifndef BATADV_SOURCE_VERSION
-<<<<<<<
-#define BATADV_SOURCE_VERSION "2018.3"
-=======
#define BATADV_SOURCE_VERSION "2018.4"
->>>>>>>
#endif
/* B.A.T.M.A.N. parameters */
Please pull or let me know of any problem!
Here are some batman-adv bugfixes:
- Avoid ELP information leak, by Sven Eckelmann
- Fix sysfs segfault issues, by Sven Eckelmann (2 patches)
- Fix locking when adding entries in various lists,
by Sven Eckelmann (5 patches)
- Fix refcount if queue_work() fails, by Marek Lindner (2 patches)
- Fixup forgotten version bump, by Sven Eckelmann
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
one srcu locking fix and one fix for GGTT clear when destroy vGPU."
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJbomjjAAoJEPpiX2QO6xPKlaMH/0sp97hPs11qVzYNrKk3Znh8
DJaI9IzRWfmSwLbfnpyywK7VqqErUltRSwUW+R8X2FqLXeG4shni154/jRdIMy1a
zx7Or/8fIyvVbCEJteMvn+Lv+8ucm8tTG3YL9JqQj7blyo3T1JbtA8zsIoVgug3T
pf4niyqcoO1plpZUsrnGKHmdrhUG+oGUkG6AWOBS8NlGgobvFY5nviyfVhdLEyG1
JZRjruFRnVNmyIgyUCHwSN9ILO6DDykMW6xpqv7CIm8eLcImetHQvwfgEsl8mMUq
SCT5EoUEnzSJrlRHkzoso4X7slM35wJ/JNnCN3NsmznWSs3FoIuFt3R3qsD8GlE=
=XeR4
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-fixes-2018-09-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Only fixes coming from gvt containing "Two more BXT fixes from Colin,
one srcu locking fix and one fix for GGTT clear when destroy vGPU."
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180919151915.GA6309@intel.com
- Fix crash in vgem in drm_drv_uses_atomic_modeset.
- Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries.
- Fix compiler warning for unused connector_funcs.
- Fix null pointer deref on UDL unplug.
- Disable DRM support for sun4i's R40 for now.
(Not all patches went in for v4.19, so it has to wait a cycle.)
- NULL-terminate the of_device_id table in pl111.
- Make sure vc4 NV12 planar format works when displaying an unscaled fb.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAluiXbsACgkQ/lWMcqZw
E8P9MBAAjmltMZr9KbmtksYSDFHVldiTqwiToPDl4iZPmMDKCQQP14apJhqwFqdO
pa+N3n7zrbR9PTUcPxt2pfT3I8J7vCGARMc66wnlPbrKDes+dkKm7KqCRFJGcyrD
faN++FGfTBn3rsLo1iM7mLOMVE+72B5gdjcxIqewEXSxWjX9ED6N7JaVR7krcQbs
MVT/ENvLZTRVCYla+eey+wQoZR/bh/E7HtuvqsLRaQOGSk6Go2gBzEiZiWfT+6sS
BzEXaYKL61AKhsh68oiPB2elxVWrnPyf3liLAzoTF0MhXuGxmlu9F50jByQvDuz8
lAzm53Hg5uFj6Ca1E81I1UDy2i5IAgaiRXGfVikeWwTsBiLgxhcRDGbQPki2rHRu
1Cs+D/F1gE94WqWhu9ydV2rU5X/5/NdDvYH0LkeD5jI9VcB8KtK89r3zXkxh3f9B
BfhVOGq3RTVgdAFFPujRrZCTQyyNW8zo51mYmncVykB//9awWE5nQcK3HGLh2wvL
0Oar5oJE3UlHa5No91zMyxmJIxZVp7SE/4A7+ih1LGTu5SyaT9K718pAgv2lpakd
HMhgF+338rCqMfL7TFqYJ2N+srXTzNRruHXdElcSg1wHbfEFejyMt0KRtv0x32qE
9IJ1CFuJVWgQ5pXu5zbj+NLKo5kR4ow0BCvsk7HCWiqkJ5N+pY8=
=bZgz
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2018-09-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v4.19-rc5:
- Fix crash in vgem in drm_drv_uses_atomic_modeset.
- Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries.
- Fix compiler warning for unused connector_funcs.
- Fix null pointer deref on UDL unplug.
- Disable DRM support for sun4i's R40 for now.
(Not all patches went in for v4.19, so it has to wait a cycle.)
- NULL-terminate the of_device_id table in pl111.
- Make sure vc4 NV12 planar format works when displaying an unscaled fb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/dda393bb-f13f-8d36-711b-cacfc578e5a3@linux.intel.com
Test guest access to MSR_PLATFORM_INFO when the capability is enabled
or disabled.
Signed-off-by: Drew Schmitt <dasch@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add KVM_CAP_MSR_PLATFORM_INFO so that userspace can disable guest access
to reads of MSR_PLATFORM_INFO.
Disabling access to reads of this MSR gives userspace the control to "expose"
this platform-dependent information to guests in a clear way. As it exists
today, guests that read this MSR would get unpopulated information if userspace
hadn't already set it (and prior to this patch series, only the CPUID faulting
information could have been populated). This existing interface could be
confusing if guests don't handle the potential for incorrect/incomplete
information gracefully (e.g. zero reported for base frequency).
Signed-off-by: Drew Schmitt <dasch@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Allow userspace to set turbo bits in MSR_PLATFORM_INFO. Previously, only
the CPUID faulting bit was settable. But now any bit in
MSR_PLATFORM_INFO would be settable. This can be used, for example, to
convey frequency information about the platform on which the guest is
running.
Signed-off-by: Drew Schmitt <dasch@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
According to section "Checks on VMX Controls" in Intel SDM vol 3C, the
following check needs to be enforced on vmentry of L2 guests:
If the 'enable VPID' VM-execution control is 1, the value of the
of the VPID VM-execution control field must not be 0000H.
Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Reviewed-by: Mark Kanda <mark.kanda@oracle.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
According to section "Checks on VMX Controls" in Intel SDM vol 3C,
the following check needs to be enforced on vmentry of L2 guests:
- Bits 5:0 of the posted-interrupt descriptor address are all 0.
- The posted-interrupt descriptor address does not set any bits
beyond the processor's physical-address width.
Signed-off-by: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Reviewed-by: Mark Kanda <mark.kanda@oracle.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In case L1 do not intercept L2 HLT or enter L2 in HLT activity-state,
it is possible for a vCPU to be blocked while it is in guest-mode.
According to Intel SDM 26.6.5 Interrupt-Window Exiting and
Virtual-Interrupt Delivery: "These events wake the logical processor
if it just entered the HLT state because of a VM entry".
Therefore, if L1 enters L2 in HLT activity-state and L2 has a pending
deliverable interrupt in vmcs12->guest_intr_status.RVI, then the vCPU
should be waken from the HLT state and injected with the interrupt.
In addition, if while the vCPU is blocked (while it is in guest-mode),
it receives a nested posted-interrupt, then the vCPU should also be
waken and injected with the posted interrupt.
To handle these cases, this patch enhances kvm_vcpu_has_events() to also
check if there is a pending interrupt in L2 virtual APICv provided by
L1. That is, it evaluates if there is a pending virtual interrupt for L2
by checking RVI[7:4] > VPPR[7:4] as specified in Intel SDM 29.2.1
Evaluation of Pending Interrupts.
Note that this also handles the case of nested posted-interrupt by the
fact RVI is updated in vmx_complete_nested_posted_interrupt() which is
called from kvm_vcpu_check_block() -> kvm_arch_vcpu_runnable() ->
kvm_vcpu_running() -> vmx_check_nested_events() ->
vmx_complete_nested_posted_interrupt().
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
VMX cannot be enabled under SMM, check it when CR4 is set and when nested
virtualization state is restored.
This should fix some WARNs reported by syzkaller, mostly around
alloc_shadow_vmcs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The functions
kvm_load_guest_fpu()
kvm_put_guest_fpu()
are only used locally, make them static. This requires also that both
functions are moved because they are used before their implementation.
Those functions were exported (via EXPORT_SYMBOL) before commit
e5bb40251a ("KVM: Drop kvm_{load,put}_guest_fpu() exports").
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These structures are going to be used from KVM code so let's make
their names reflect their Hyper-V origin.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A VMX preemption timer value of '0' is guaranteed to cause a VMExit
prior to the CPU executing any instructions in the guest. Use the
preemption timer (if it's supported) to trigger immediate VMExit
in place of the current method of sending a self-IPI. This ensures
that pending VMExit injection to L1 occurs prior to executing any
instructions in the guest (regardless of nesting level).
When deferring VMExit injection, KVM generates an immediate VMExit
from the (possibly nested) guest by sending itself an IPI. Because
hardware interrupts are blocked prior to VMEnter and are unblocked
(in hardware) after VMEnter, this results in taking a VMExit(INTR)
before any guest instruction is executed. But, as this approach
relies on the IPI being received before VMEnter executes, it only
works as intended when KVM is running as L0. Because there are no
architectural guarantees regarding when IPIs are delivered, when
running nested the INTR may "arrive" long after L2 is running e.g.
L0 KVM doesn't force an immediate switch to L1 to deliver an INTR.
For the most part, this unintended delay is not an issue since the
events being injected to L1 also do not have architectural guarantees
regarding their timing. The notable exception is the VMX preemption
timer[1], which is architecturally guaranteed to cause a VMExit prior
to executing any instructions in the guest if the timer value is '0'
at VMEnter. Specifically, the delay in injecting the VMExit causes
the preemption timer KVM unit test to fail when run in a nested guest.
Note: this approach is viable even on CPUs with a broken preemption
timer, as broken in this context only means the timer counts at the
wrong rate. There are no known errata affecting timer value of '0'.
[1] I/O SMIs also have guarantees on when they arrive, but I have
no idea if/how those are emulated in KVM.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
[Use a hook for SVM instead of leaving the default in x86.c - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Provide a singular location where the VMX preemption timer bit is
set/cleared so that future usages of the preemption timer can ensure
the VMCS bit is up-to-date without having to modify unrelated code
paths. For example, the preemption timer can be used to force an
immediate VMExit. Cache the status of the timer to avoid redundant
VMREAD and VMWRITE, e.g. if the timer stays armed across multiple
VMEnters/VMExits.
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
A VMX preemption timer value of '0' at the time of VMEnter is
architecturally guaranteed to cause a VMExit prior to the CPU
executing any instructions in the guest. This architectural
definition is in place to ensure that a previously expired timer
is correctly recognized by the CPU as it is possible for the timer
to reach zero and not trigger a VMexit due to a higher priority
VMExit being signalled instead, e.g. a pending #DB that morphs into
a VMExit.
Whether by design or coincidence, commit f4124500c2 ("KVM: nVMX:
Fully emulate preemption timer") special cased timer values of '0'
and '1' to ensure prompt delivery of the VMExit. Unlike '0', a
timer value of '1' has no has no architectural guarantees regarding
when it is delivered.
Modify the timer emulation to trigger immediate VMExit if and only
if the timer value is '0', and document precisely why '0' is special.
Do this even if calibration of the virtual TSC failed, i.e. VMExit
will occur immediately regardless of the frequency of the timer.
Making only '0' a special case gives KVM leeway to be more aggressive
in ensuring the VMExit is injected prior to executing instructions in
the nested guest, and also eliminates any ambiguity as to why '1' is
a special case, e.g. why wasn't the threshold for a "short timeout"
set to 10, 100, 1000, etc...
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
kvm_commit_zap_page() has been renamed to kvm_mmu_commit_zap_page()
This patch is to fix the commit.
Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
I run into the following error
testing/selftests/kvm/dirty_log_test.c:285: undefined reference to `pthread_create'
testing/selftests/kvm/dirty_log_test.c:297: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
my gcc version is gcc version 4.8.4
"-pthread" would work everywhere
Signed-off-by: Lei Yang <Lei.Yang@windriver.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Here is the code path which shows kvm_mmu_setup() is invoked after
kvm_mmu_create(). Since kvm_mmu_setup() is only invoked in this code path,
this means the root_hpa and prev_roots are guaranteed to be invalid. And
it is not necessary to reset it again.
kvm_vm_ioctl_create_vcpu()
kvm_arch_vcpu_create()
vmx_create_vcpu()
kvm_vcpu_init()
kvm_arch_vcpu_init()
kvm_mmu_create()
kvm_arch_vcpu_setup()
kvm_mmu_setup()
kvm_init_mmu()
This patch set reset_roots to false in kmv_mmu_setup().
Fixes: 50c28f21d0
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Reviewed-by: Liran Alon <liran.alon@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
kvm should not attempt to read guest PDPTEs when CR0.PG = 0 and
CR4.PAE = 1.
Signed-off-by: Junaid Shahid <junaids@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When VMX is used with flexpriority disabled (because of no support or
if disabled with module parameter) MMIO interface to lAPIC is still
available in x2APIC mode while it shouldn't be (kvm-unit-tests):
PASS: apic_disable: Local apic enabled in x2APIC mode
PASS: apic_disable: CPUID.1H:EDX.APIC[bit 9] is set
FAIL: apic_disable: *0xfee00030: 50014
The issue appears because we basically do nothing while switching to
x2APIC mode when APIC access page is not used. apic_mmio_{read,write}
only check if lAPIC is disabled before proceeding to actual write.
When APIC access is virtualized we correctly manipulate with VMX controls
in vmx_set_virtual_apic_mode() and we don't get vmexits from memory writes
in x2APIC mode so there's no issue.
Disabling MMIO interface seems to be easy. The question is: what do we
do with these reads and writes? If we add apic_x2apic_mode() check to
apic_mmio_in_range() and return -EOPNOTSUPP these reads and writes will
go to userspace. When lAPIC is in kernel, Qemu uses this interface to
inject MSIs only (see kvm_apic_mem_write() in hw/i386/kvm/apic.c). This
somehow works with disabled lAPIC but when we're in xAPIC mode we will
get a real injected MSI from every write to lAPIC. Not good.
The simplest solution seems to be to just ignore writes to the region
and return ~0 for all reads when we're in x2APIC mode. This is what this
patch does. However, this approach is inconsistent with what currently
happens when flexpriority is enabled: we allocate APIC access page and
create KVM memory region so in x2APIC modes all reads and writes go to
this pre-allocated page which is, btw, the same for all vCPUs.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
libc_compat.h is used by libbpf so make sure it's licensed under
LGPL or BSD license. The license change should be OK, I'm the only
author of the file.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
Acked-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Use different loop variables for the inner and outer loop. This avoids
that an infinite loop occurs if there are more RDMA channels than
target->req_ring_size.
Fixes: d92c0da71a ("IB/srp: Add multichannel support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
A couple of small but important fixes, one affecting big endian and
the other fixing a BUG_ON in scatterlist processing.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCW6IviSYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishdrPAP4h8ouR
z4qewZsVK9hwySouIfC2xAPRu7aFUBEPw12O4gEAshqLg/61w7PYS0t9NjQVpRw3
nR6xr6ymTbImn09w1Wg=
=MQ30
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
James writes:
"SCSI fixes on 20180919
A couple of small but important fixes, one affecting big endian and
the other fixing a BUG_ON in scatterlist processing.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>"
When a driver domain (e.g. dom0) is running out of maptrack entries it
can't map any more foreign domain pages. Instead of silently stalling
the affected domUs issue a rate limited warning in this case in order
to make it easier to detect that situation.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Otherwise we may leak kernel stack for events that sample user
registers.
Reported-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: stable@vger.kernel.org
Borislav is effectivly maintaining parts of X86 already, make it official.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Borislav Petkov <bp@alien8.de>
Sync syscall to DAX file needs to flush processor cache, but it
currently does not flush to existing DAX files. This is because
'ext2_da_aops' is set to address_space_operations of existing DAX
files, instead of 'ext2_dax_aops', since S_DAX flag is set after
ext2_set_aops() in the open path.
Similar to ext4, change ext2_iget() to initialize i_flags before
ext2_set_aops().
Fixes: fb094c9074 ("ext2, dax: introduce ext2_dax_aops")
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Suggested-by: Jan Kara <jack@suse.cz>
Cc: Jan Kara <jack@suse.cz>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jan Kara <jack@suse.cz>
- Fix the build on !_GNU_SOURCE libc systems such as Alpine Linux/musl
libc due to usage of strerror_r glibc variant on libbpf (Arnaldo Carvalho de Melo)
- Fix out-of-tree asciidoctor man page generation (Ben Hutchings)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQR2GiIUctdOfX2qHhGyPKLppCJ+JwUCW6EaQwAKCRCyPKLppCJ+
J2GjAP9j3onRb93lyoLP5eUAxdSrEmFQ/myn7rLuDLZoo2RVPQD+MqCwf6hlNQgl
wKM4jrJT/mwV53a3+bDeNoXBCEbuxQw=
=hr0o
-----END PGP SIGNATURE-----
Merge tag 'perf-urgent-for-mingo-4.19-20180918' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
- Fix the build on !_GNU_SOURCE libc systems such as Alpine Linux/musl
libc due to usage of strerror_r glibc variant on libbpf (Arnaldo Carvalho de Melo)
- Fix out-of-tree asciidoctor man page generation (Ben Hutchings)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The first argument to WARN_ONCE() is a condition.
Fixes: 5800dc5c19 ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Alok Kataria <akataria@vmware.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: virtualization@lists.linux-foundation.org
Cc: kernel-janitors@vger.kernel.org
Link: https://lkml.kernel.org/r/20180919103553.GD9238@mwanda
The A64 HDMI PHY seems to be not able to use the second video PLL as
clock parent in experiments.
Drop the support for the second PLL from A64 HDMI PHY driver.
Fixes: b46e2c9f5f ("drm/sun4i: Add support for A64 HDMI PHY")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180916043409.62374-2-icenowy@aosc.io
Crypto stuff from Herbert:
"This push fixes a potential boot hang in ccp and an incorrect
CPU capability check in aegis/morus on x86."
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2
crypto: ccp - add timeout support in the SEV command
