Changes in 5.10.49
KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path
media: uvcvideo: Support devices that report an OT as an entity source
Hexagon: fix build errors
Hexagon: add target builtins to kernel
Hexagon: change jumps to must-extend in futex_atomic_*
xen/events: reset active flag for lateeoi events later
Linux 5.10.49
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ieb1bda402419f08614fbb1b0208a83c6df0abf2d
Changes in 5.10.48
scsi: sr: Return appropriate error code when disk is ejected
gpio: mxc: Fix disabled interrupt wake-up support
drm/nouveau: fix dma_address check for CPU/GPU sync
gpio: AMD8111 and TQMX86 require HAS_IOPORT_MAP
RDMA/mlx5: Block FDB rules when not in switchdev mode
Revert "KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack"
Linux 5.10.48
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie66f49fdd4e28b369b134dfb99aab7c0f0e3bd18
commit 4ca052b4ea upstream.
Some devices reference an output terminal as the source of extension
units. This is incorrect, as output terminals only have an input pin,
and thus can't be connected to any entity in the forward direction. The
resulting topology would cause issues when registering the media
controller graph. To avoid this problem, connect the extension unit to
the source of the output terminal instead.
While at it, and while no device has been reported to be affected by
this issue, also handle forward scans where two output terminals would
be connected together, and skip the terminals found through such an
invalid connection.
Reported-and-tested-by: John Nealy <jnealy3@yahoo.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 25edcc50d7 upstream.
The Facility Status and Control Register is a privileged SPR that
defines the availability of some features in problem state. Since it
can be written by the guest, we must restore it to the previous host
value after guest exit.
This restoration is currently done by taking the value from
current->thread.fscr, which in the P9 path is not enough anymore
because the guest could context switch the QEMU thread, causing the
guest-current value to be saved into the thread struct.
The above situation manifested when running a QEMU linked against a
libc with System Call Vectored support, which causes scv
instructions to be run by QEMU early during the guest boot (during
SLOF), at which point the FSCR is 0 due to guest entry. After a few
scv calls (1 to a couple hundred), the context switching happens and
the QEMU thread runs with the guest value, resulting in a Facility
Unavailable interrupt.
This patch saves and restores the host value of FSCR in the inner
guest entry loop in a way independent of current->thread.fscr. The old
way of doing it is still kept in place because it works for the old
entry path.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Cc: Georgy Yakovlev <gyakovlev@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f71a53d118 upstream.
Restore CR4.LA57 to the mmu_role to fix an amusing edge case with nested
virtualization. When KVM (L0) is using TDP, CR4.LA57 is not reflected in
mmu_role.base.level because that tracks the shadow root level, i.e. TDP
level. Normally, this is not an issue because LA57 can't be toggled
while long mode is active, i.e. the guest has to first disable paging,
then toggle LA57, then re-enable paging, thus ensuring an MMU
reinitialization.
But if L1 is crafty, it can load a new CR4 on VM-Exit and toggle LA57
without having to bounce through an unpaged section. L1 can also load a
new CR3 on exit, i.e. it doesn't even need to play crazy paging games, a
single entry PML5 is sufficient. Such shenanigans are only problematic
if L0 and L1 use TDP, otherwise L1 and L2 share an MMU that gets
reinitialized on nested VM-Enter/VM-Exit due to mmu_role.base.guest_mode.
Note, in the L2 case with nested TDP, even though L1 can switch between
L2s with different LA57 settings, thus bypassing the paging requirement,
in that case KVM's nested_mmu will track LA57 in base.level.
This reverts commit 8053f924ca.
Fixes: 8053f924ca ("KVM: x86/mmu: Drop kvm_mmu_extended_role.cr4_la57 hack")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210622175739.3610207-6-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c6414e1a2b ]
Both of these drivers use ioport_map(), so they need to
depend on HAS_IOPORT_MAP. Otherwise, they cannot be built
even with COMPILE_TEST on architectures without an ioport
implementation, such as ARCH=um.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3093e6cca3 ]
A disabled/masked interrupt marked as wakeup source must be re-enable
and unmasked in order to be able to wake-up the host. That can be done
by flaging the irqchip with IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND.
Note: It 'sometimes' works without that change, but only thanks to the
lazy generic interrupt disabling (keeping interrupt unmasked).
Reported-by: Michal Koziel <michal.koziel@emlogic.no>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
In change Iab3971cd0d78d669536b8eb0505c60caa3aafeee the
cfg80211 and mac80211 drivers were switched to modules, so we
need to add them as such to the hikey960_gki.fragment.
With this change, hikey960 boots and wifi comes up.
Bug: 189918667
Fixes: Iab3971cd0d78d669536b8eb0505c60caa3aafeee
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I8cd3dd3dc76852e270b7b4ba518323af92ff6dda
Remove CONFIG_CFG80211 and CONFIG_MAC80211 from gki_defconfig
to allow vendors to incorporate features that have landed upstream.
Also need to update symbol lists since the related 80211
symbols are no longer exported from the core kernel.
Bug: 189918667
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Iab3971cd0d78d669536b8eb0505c60caa3aafeee
This reverts commit bba0d8a87e.
CFG80211 changing to a module so these configs go into device-specific
defconfig fragments.
Bug: 189918667
Change-Id: Ie4b70407369da3c865541e4857c3ba18fec24587
This reverts commit 9132fbe545.
Reason for revert: mmap_count is no longer used for reporting dma-bufs
and introduces subtle bugs related to changing the vm_ops
Bug: 192459295
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: Id07802e5a3e18918c5c46e31b73be4a594f7dc26
This reverts commit fca37c251a.
Reason for revert: mmap_count is no longer used for reporting dma-bufs and introduces subtle bugs related to changing the vm_ops
Bug: 192459295
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I52fb55e1048a151fae7641c9646a231d59b3224d
Add ABI padding to some of the data structures to accommodate
new eMMC features enablement later.
Bug: 192337957
Change-Id: Ica3f96ea004fb89e4b46ef9734864c655cdcd277
Signed-off-by: Sahitya Tummala <quic_stummala@quicinc.com>
This change adds the rproc_coredump() and rproc_coredump_cleanup()
APIs to the qcom symbol list.
Bug: 188764827
Change-Id: I32a56f5d3caabc61ed94f6de0d7daa29becb490d
Signed-off-by: Siddharth Gupta <quic_sidgup@quicinc.com>
Add the the symbols exported by the remoteproc vendor hook to the
qcom symbol list.
Change-Id: Iffd58aa5d367141de1c065488519b29fb802fd86
Signed-off-by: Siddharth Gupta <quic_sidgup@quicinc.com>
For vendor specific data in struct cfs_rq.
Bug: 188947181
Signed-off-by: Rick Yiu <rickyiu@google.com>
Change-Id: I7c322c6812829c19014426b5721cd1fb0c37a53f
We need to obtain the pid and tid information of the caller in the async binder transaction.
So we need to add the pid and tid information in the async binder transaction.
Bug: 190413570
Signed-off-by: zhang chuang <zhangchuang3@xiaomi.com>
Change-Id: If67c972aa53196d626ccfeb46b6b61e43ddc57ae
0day robot reported a 9.2% regression for will-it-scale mmap1 test
case[1], caused by commit 57efa1fe59 ("mm/gup: prevent gup_fast from
racing with COW during fork").
Further debug shows the regression is due to that commit changes the
offset of hot fields 'mmap_lock' inside structure 'mm_struct', thus some
cache alignment changes.
From the perf data, the contention for 'mmap_lock' is very severe and
takes around 95% cpu cycles, and it is a rw_semaphore
struct rw_semaphore {
atomic_long_t count; /* 8 bytes */
atomic_long_t owner; /* 8 bytes */
struct optimistic_spin_queue osq; /* spinner MCS lock */
...
Before commit 57efa1fe59 adds the 'write_protect_seq', it happens to
have a very optimal cache alignment layout, as Linus explained:
"and before the addition of the 'write_protect_seq' field, the
mmap_sem was at offset 120 in 'struct mm_struct'.
Which meant that count and owner were in two different cachelines,
and then when you have contention and spend time in
rwsem_down_write_slowpath(), this is probably *exactly* the kind
of layout you want.
Because first the rwsem_write_trylock() will do a cmpxchg on the
first cacheline (for the optimistic fast-path), and then in the
case of contention, rwsem_down_write_slowpath() will just access
the second cacheline.
Which is probably just optimal for a load that spends a lot of
time contended - new waiters touch that first cacheline, and then
they queue themselves up on the second cacheline."
After the commit, the rw_semaphore is at offset 128, which means the
'count' and 'owner' fields are now in the same cacheline, and causes
more cache bouncing.
Currently there are 3 "#ifdef CONFIG_XXX" before 'mmap_lock' which will
affect its offset:
CONFIG_MMU
CONFIG_MEMBARRIER
CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES
The layout above is on 64 bits system with 0day's default kernel config
(similar to RHEL-8.3's config), in which all these 3 options are 'y'.
And the layout can vary with different kernel configs.
Relayouting a structure is usually a double-edged sword, as sometimes it
can helps one case, but hurt other cases. For this case, one solution
is, as the newly added 'write_protect_seq' is a 4 bytes long seqcount_t
(when CONFIG_DEBUG_LOCK_ALLOC=n), placing it into an existing 4 bytes
hole in 'mm_struct' will not change other fields' alignment, while
restoring the regression.
Link: https://lore.kernel.org/lkml/20210525031636.GB7744@xsang-OptiPlex-9020/ [1]
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Bug: 161946584
(cherry picked from commit 2e3025434a)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9142789c5d57d167e5bb1f450d914bf2111894a2
As restricted hooks have been introduced, regular vendor hooks are no
longer necessary.
Bug: 187917024
Change-Id: Ia70e9dd1bd7373e19bdc82e90a2384201076bc0b
Signed-off-by: Shaleen Agrawal <shalagra@codeaurora.org>
Enable CONFIG_BLK_CGROUP_IOCOST to help control IO resources.
Bug: 188749221
Change-Id: I611b3ff5929d0a998fa6241967887803636b7588
Signed-off-by: Yang Yang <yang.yang@vivo.com>
Add ANDROID_OEM_DATA for implement of oem gki
Bug: 188749221
Change-Id: I1feba2334aa34e3bc46eb9d0217118485405beb4
Signed-off-by: Yang Yang <yang.yang@vivo.com>
Add ANDROID_OEM_DATA for implement of oem gki
Bug: 188749221
Change-Id: Ide8378a898de01a34d8ca3c34472844cd4ffa71c
Signed-off-by: Yang Yang <yang.yang@vivo.com>
Add ANDROID_OEM_DATA for implement of oem gki
Bug: 188749221
Change-Id: I96b1c690fda172d0c490e944557a674a37620742
Signed-off-by: Yang Yang <yang.yang@vivo.com>
Need symbols for newly added CAN drivers
Bug: 190375772
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ibaa1c0963e2e5efb0cf77e6661a683cb00f095d9
We can make use of this commit, to elaborate some more of the host
control mode logic, explaining what role play each and every variable.
While at it, allow those parameters to be configurable.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-13-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: Ib05c6643c69504b8d9442b0024cfe1b0b687a4ce
in host control mode the host is the originator of map requests. To not
flood the device with map requests, use a simple throttling mechanism
that limits the number of inflight map requests.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-10-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I75a5ced3be60569adcd75befa17d8a6340c147fd
In order not to hang on to “cold” regions, we shall inactivate a
region that has no READ access for a predefined amount of time -
READ_TO_MS. For that purpose we shall monitor the active regions list,
polling it on every POLLING_INTERVAL_MS. On timeout expiry we shall add
the region to the "to-be-inactivated" list, unless it is clean and did
not exhaust its READ_TO_EXPIRIES - another parameter.
All this does not apply to pinned regions.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-9-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I2d2efbbc612ccec6ef7036cc1e1d31bd8bfd4174
The spec does not define what is the host's recommended response when
the device send hpb dev reset response (oper 0x2).
We will update all active hpb regions: mark them and do that on the next
read.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-8-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: Ibe87969a4130b4e77f5d163771648679bc5ac7e8
In host mode, the host is expected to send HPB-WRITE-BUFFER with
buffer-id = 0x1 when it inactivates a region.
Use the map-requests pool as there is no point in assigning a
designated cache for umap-requests.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-7-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I1a6696b38d4abfb4d9fbe44e84016a6238825125
In host mode, eviction is considered an extreme measure.
verify that the entering region has enough reads, and the exiting
region has much less reads.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-6-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: Ia08e3af69302c4f0474efa7c616832dde48df4e0
In host control mode, reads are the major source of activation trials.
Keep track of those reads counters, for both active as well inactive
regions.
We reset the read counter upon write - we are only interested in "clean"
reads.
Keep those counters normalized, as we are using those reads as a
comparative score, to make various decisions.
If during consecutive normalizations an active region has exhaust its
reads - inactivate it.
while at it, protect the {active,inactive}_count stats by adding them
into the applicable handler.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-5-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I0541c39e3dd7656ca1816cac3599ab73eb8697a8
Given a transfer length, set_dirty meticulously runs over all the
entries, across subregions and regions if needed. Currently its only use
is to mark dirty blocks, but soon HCM may profit from it as well, when
managing its read counters.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-4-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Daejun Park <daejun7.park@samsung.com>
Change-Id: I916f4bf80490e31e5ef797d67647a41a07cefa02
In device control mode, the device may recommend the host to either
activate or inactivate a region, and the host should follow. Meaning
those are not actually recommendations, but more of instructions.
On the contrary, in host control mode, the recommendation protocol is
slightly changed:
a) The device may only recommend the host to update a subregion of an
already-active region. And,
b) The device may *not* recommend to inactivate a region.
Furthermore, in host control mode, the host may choose not to follow any
of the device's recommendations. However, in case of a recommendation to
update an active and clean subregion, it is better to follow those
recommendation because otherwise the host has no other way to know that
some internal relocation took place.
Bug: 183467926
Bug: 170940265
Bug: 183454255
Link: https://lore.kernel.org/lkml/20210607061401.58884-3-avri.altman@wdc.com/
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I02cb053ae4e7fdadd663f9190c95e5f5a79c0e4b
