Setting non-zero values to SYNIC/STIMER MSRs activates certain features,
this should not happen when KVM_CAP_HYPERV_SYNIC{,2} was not activated.
Note, it would've been better to forbid writing anything to SYNIC/STIMER
MSRs, including zeroes, however, at least QEMU tries clearing
HV_X64_MSR_STIMER0_CONFIG without SynIC. HV_X64_MSR_EOM MSR is somewhat
'special' as writing zero there triggers an action, this also should not
happen when SynIC wasn't activated.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220325132140.25650-4-vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When kvm_irq_delivery_to_apic_fast() is called with APIC_DEST_SELF
shorthand, 'src' must not be NULL. Crash the VM with KVM_BUG_ON()
instead of crashing the host.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220325132140.25650-3-vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When KVM_CAP_HYPERV_SYNIC{,2} is activated, KVM already checks for
irqchip_in_kernel() so normally SynIC irqs should never be set. It is,
however, possible for a misbehaving VMM to write to SYNIC/STIMER MSRs
causing erroneous behavior.
The immediate issue being fixed is that kvm_irq_delivery_to_apic()
(kvm_irq_delivery_to_apic_fast()) crashes when called with
'irq.shorthand = APIC_DEST_SELF' and 'src == NULL'.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20220325132140.25650-2-vkuznets@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add a section to document all the different ways in which the KVM API sucks.
I am sure there are way more, give people a place to vent so that userspace
authors are aware.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220322110712.222449-4-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add a file to document all the different ways in which the virtual CPU
emulation is imperfect. Include an example to show how to document
such errata.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Reviewed-by: Oliver Upton <oupton@google.com>
Message-Id: <20220322110712.222449-3-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ARM already has an arm/ subdirectory, but s390 and x86 do not even though
they have a relatively large number of files specific to them. Create
new directories in Documentation/virt/kvm for these two architectures
as well.
While at it, group the API documentation and the developer documentation
in the table of contents.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220322110712.222449-2-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
kvm->mn_invalidate_lock and kvm->slots_arch_lock were not included in the
documentation, add them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220322110720.222499-3-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Separate the various locks clearly, and include the new names of blocked_vcpu_on_cpu_lock
and blocked_vcpu_on_cpu.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220322110720.222499-2-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Clang warns:
arch/x86/kvm/cpuid.c:739:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
default:
^
arch/x86/kvm/cpuid.c:739:2: note: insert 'break;' to avoid fall-through
default:
^
break;
1 error generated.
Clang is a little more pedantic than GCC, which does not warn when
falling through to a case that is just break or return. Clang's version
is more in line with the kernel's own stance in deprecated.rst, which
states that all switch/case blocks must end in either break,
fallthrough, continue, goto, or return. Add the missing break to silence
the warning.
Fixes: f144c49e8c ("KVM: x86: synthesize CPUID leaf 0x80000021h if useful")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Message-Id: <20220322152906.112164-1-nathan@kernel.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* clk-sifive:
clk: sifive: Move all stuff into SoCs header files from C files
clk: sifive: Add SoCs prefix in each SoCs-dependent data
riscv: dts: Change the macro name of prci in each device node
dt-bindings: change the macro name of prci in header files and example
clk: sifive: duplicate the macro definitions for the time being
* clk-visconti:
clk: visconti: prevent array overflow in visconti_clk_register_gates()
- Make clk_set_rate_range() re-evaluate the limits each time
- Introduce various clk_set_rate_range() tests
- Add clk_drop_range() to drop a previously set range
- Support for NCO blocks on Apple SoCs
* clk-range:
clk: Drop the rate range on clk_put()
clk: test: Test clk_set_rate_range on orphan mux
clk: Initialize orphan req_rate
clk: bcm: rpi: Run some clocks at the minimum rate allowed
clk: bcm: rpi: Set a default minimum rate
clk: bcm: rpi: Add variant structure
clk: Add clk_drop_range
clk: Always set the rate on clk_set_range_rate
clk: Use clamp instead of open-coding our own
clk: Always clamp the rounded rate
clk: Enforce that disjoints limits are invalid
clk: Introduce Kunit Tests for the framework
clk: Fix clk_hw_get_clk() when dev is NULL
* clk-uniphier:
clk: uniphier: Fix fixed-rate initialization
* clk-apple:
clk: clk-apple-nco: Allow and fix module building
MAINTAINERS: Add clk-apple-nco under ARM/APPLE MACHINE
clk: clk-apple-nco: Add driver for Apple NCO
dt-bindings: clock: Add Apple NCO
* clk-qcom: (61 commits)
clk: qcom: gcc-msm8994: Fix gpll4 width
dt-bindings: clock: fix dt_binding_check error for qcom,gcc-other.yaml
clk: qcom: Add display clock controller driver for SM6125
dt-bindings: clock: add QCOM SM6125 display clock bindings
clk: qcom: Fix sorting of SDX_GCC_65 in Makefile and Kconfig
clk: qcom: gcc: Add emac GDSC support for SM8150
clk: qcom: gcc: sm8150: Fix some identation issues
clk: qcom: gcc: Add UFS_CARD and UFS_PHY GDSCs for SM8150
clk: qcom: gcc: Add PCIe0 and PCIe1 GDSC for SM8150
clk: qcom: clk-rcg2: Update the frac table for pixel clock
clk: qcom: clk-rcg2: Update logic to calculate D value for RCG
clk: qcom: smd: Add missing MSM8998 RPM clocks
clk: qcom: smd: Add missing RPM clocks for msm8992/4
dt-bindings: clock: qcom: rpmcc: Add RPM Modem SubSystem (MSS) clocks
clk: qcom: gcc-ipq806x: add CryptoEngine resets
dt-bindings: reset: add ipq8064 ce5 resets
clk: qcom: gcc-ipq806x: add CryptoEngine clocks
dt-bindings: clock: add ipq8064 ce5 clk define
clk: qcom: gcc-ipq806x: add additional freq for sdc table
clk: qcom: clk-rcg: add clk_rcg_floor_ops ops
...
In case there are only one gate or the two_gate is 0 the clk1 clock
passed is not used. We are passing 0 which is arm_pll.
Pass a invalid clock instead.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Link: https://lore.kernel.org/r/20220222130903.17235-3-shubhrajyoti.datta@xilinx.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
This reverts commit 3d3aab1b97.
Now that the KVM module's lifetime is tied to kvm.users_count, there is
no need to also tie it's lifetime to the lifetime of the VM and vCPU
file descriptors.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220303183328.1499189-3-dmatlack@google.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tie the lifetime the KVM module to the lifetime of each VM via
kvm.users_count. This way anything that grabs a reference to the VM via
kvm_get_kvm() cannot accidentally outlive the KVM module.
Prior to this commit, the lifetime of the KVM module was tied to the
lifetime of /dev/kvm file descriptors, VM file descriptors, and vCPU
file descriptors by their respective file_operations "owner" field.
This approach is insufficient because references grabbed via
kvm_get_kvm() do not prevent closing any of the aforementioned file
descriptors.
This fixes a long standing theoretical bug in KVM that at least affects
async page faults. kvm_setup_async_pf() grabs a reference via
kvm_get_kvm(), and drops it in an asynchronous work callback. Nothing
prevents the VM file descriptor from being closed and the KVM module
from being unloaded before this callback runs.
Fixes: af585b921e ("KVM: Halt vcpu if page it tries to access is swapped out")
Fixes: 3d3aab1b97 ("KVM: set owner of cpu and vm file operations")
Cc: stable@vger.kernel.org
Suggested-by: Ben Gardon <bgardon@google.com>
[ Based on a patch from Ben implemented for Google's kernel. ]
Signed-off-by: David Matlack <dmatlack@google.com>
Message-Id: <20220303183328.1499189-2-dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Merge additional power management documentation udates for 5.18-rc1:
- Add Intel uncore frequency scaling documentation file to its
MAINTAINERS entry (Srinivas Pandruvada).
- Clean up the AMD P-state driver documentation (Jan Engelhardt).
* pm-docs:
Documentation: amd-pstate: grammar and sentence structure updates
MAINTAINERS: Add additional file to uncore frequency control
Merge OPP (Operating Performance Points) changes for 5.18-rc1.
* pm-opp:
Documentation: EM: Describe new registration method using DT
OPP: Add support of "opp-microwatt" for EM registration
PM: EM: add macro to set .active_power() callback conditionally
OPP: Add "opp-microwatt" supporting code
dt-bindings: opp: Add "opp-microwatt" entry in the OPP
dt-bindings: power: avs: qcom,cpr: Convert to DT schema
arm64: dts: qcom: qcs404: Rename CPU and CPR OPP tables
arm64: dts: qcom: msm8996: Rename cluster OPP tables
dt-bindings: opp: Convert qcom-nvmem-cpufreq to DT schema
dt-bindings: opp: qcom-opp: Convert to DT schema
arm64: dts: qcom: msm8996-mtp: Add msm8996 compatible
dt-bindings: arm: qcom: Add msm8996 and apq8096 compatibles
opp: Expose of-node's name in debugfs
We must always call req_set_fail() if the request is failed, otherwise
we won't sever links for dependent chains correctly.
Fixes: 4f57f06ce2 ("io_uring: add support for IORING_OP_MSG_RING command")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- do not zero buffer in set_memory_decrypted (Kirill A. Shutemov)
- fix return value of dma-debug __setup handlers (Randy Dunlap)
- swiotlb cleanups (Robin Murphy)
- remove most remaining users of the pci-dma-compat.h API
(Christophe JAILLET)
- share the ABI header for the DMA map_benchmark with userspace
(Tian Tao)
- update the maintainer for DMA MAPPING BENCHMARK (Xiang Chen)
- remove CONFIG_DMA_REMAP (me)
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAmJDDgsLHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYM9oBAAxm93DZCXsqektM2qJ34o1KCyfAhvTvZ1r38ab+cl
wJwmMPF6/S9MCj6XZEnCzUnXL//TnhcuYVztNpPTWqhx6QaqWmmx9yJKjoYAnHce
svVMef7iipn35w7hAPpiVR/AVwWyxQCkSC+5sgp6XX8mp7l7I3ajfO0fZ52JCcxw
12d4k1E0yjC096Kw8wXQv+rzmCAoQcK9Jj20COUO3rkgOr68ZIXse2HXUJjn76Fy
wym2rJfqJ9mdKrDHqphe1ntIzkcQNWx9xR0UVh7/e4p7Si5H8Lp8QWwC7Zw6Y2Gb
paeotIMu1uTKkcZI4K54J8PXRLA7PLrDSDFdxnKOsWNZU/inIwt9b11kr9FOaYqR
BLJ+w6bF1/PmM6q2gkOwNuoiJD5YQfwF7y+wi84VyaauM0J8ssIHYnVrCWXn0m1E
4veAkWasAYb1oaoNlDhmZEbpI+kcN3xwDyK1WbtHuGvR00oSvxl0d1viGTVXYfDA
k5rBjb7CovK8JIrFIJoMiDM4TvdauxL66IlEL7ohLDh6l1f09Q0+gsdVcAM0ObX6
zOkoulyHCFqkePvoH/xpyIrZZ9cHA228fZYC7QiBcxdWlD3dFMWkKvhajiSDQJSW
SAz94CeEDWn64Q462N+ecivKlLwz7j/TqOig5xU+/6UoMC/2a7+HIim+p6bjh8Pc
5Gg=
=C+Es
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-5.18' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping updates from Christoph Hellwig:
- do not zero buffer in set_memory_decrypted (Kirill A. Shutemov)
- fix return value of dma-debug __setup handlers (Randy Dunlap)
- swiotlb cleanups (Robin Murphy)
- remove most remaining users of the pci-dma-compat.h API
(Christophe JAILLET)
- share the ABI header for the DMA map_benchmark with userspace
(Tian Tao)
- update the maintainer for DMA MAPPING BENCHMARK (Xiang Chen)
- remove CONFIG_DMA_REMAP (me)
* tag 'dma-mapping-5.18' of git://git.infradead.org/users/hch/dma-mapping:
dma-mapping: benchmark: extract a common header file for map_benchmark definition
dma-debug: fix return value of __setup handlers
dma-mapping: remove CONFIG_DMA_REMAP
media: v4l2-pci-skeleton: Remove usage of the deprecated "pci-dma-compat.h" API
rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API
sparc: Remove usage of the deprecated "pci-dma-compat.h" API
agp/intel: Remove usage of the deprecated "pci-dma-compat.h" API
alpha: Remove usage of the deprecated "pci-dma-compat.h" API
MAINTAINERS: update maintainer list of DMA MAPPING BENCHMARK
swiotlb: simplify array allocation
swiotlb: tidy up includes
swiotlb: simplify debugfs setup
swiotlb: do not zero buffer in set_memory_decrypted()
Freescale Layerscape Lynx 28G SerDes PHYs are only present on
Freescale/NXP Layerscape SoCs.
Move PHY_FSL_LYNX_28G outside the block for ARCH_MXC, as the latter
is meant for i.MX8 SoCs, which is a different family than Layerscape.
Add a dependency on ARCH_LAYERSCAPE, to prevent asking the user about
this driver when configuring a kernel without Layerscape SoC support.
Fixes: 02e2af20f4 ("Merge tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc")
Fixes: 8f73b37cf3 ("phy: add support for the Layerscape SerDes 28G")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 53d862fac4.
It turned out that flush_kernel_vmap_range() is being called with
interrupts disabled. There's no way to flush entire cache with
interrupts disabled.
Signed-off-by: Helge Deller <deller@gmx.de>
The io-specific memcpy/memset functions use string mmio accesses to do
their work. Under SEV, the hypervisor can't emulate these instructions
because they read/write directly from/to encrypted memory.
KVM will inject a page fault exception into the guest when it is asked
to emulate string mmio instructions for an SEV guest:
BUG: unable to handle page fault for address: ffffc90000065068
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 8000100000067 P4D 8000100000067 PUD 80001000fb067 PMD 80001000fc067 PTE 80000000fed40173
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc7 #3
As string mmio for an SEV guest can not be supported by the
hypervisor, unroll the instructions for CC_ATTR_GUEST_UNROLL_STRING_IO
enabled kernels.
This issue appears when kernels are launched in recent libvirt-managed
SEV virtual machines, because virt-install started to add a tpm-crb
device to the guest by default and proactively because, raisins:
eb58c09f48
and as that commit says, the default adding of a TPM can be disabled
with "virt-install ... --tpm none".
The kernel driver for tpm-crb uses memcpy_to/from_io() functions to
access MMIO memory, resulting in a page-fault injected by KVM and
crashing the kernel at boot.
[ bp: Massage and extend commit message. ]
Fixes: d8aa7eea78 ('x86/mm: Add Secure Encrypted Virtualization (SEV) support')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220321093351.23976-1-joro@8bytes.org
SDVO is the only connector type currently returning the VBT
fixed mode directly from .get_modes(), everyone else just
adds it to the fixed_modes list and then returns that from
.get_modes(). Adjust SDVO to follow the common behaviour.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Despite the name intel_panel_edid_fixed_mode() doesn't actually
look in the EDID. All it does is dig out the preferred mode from
the connector's probed_modes list. That is also what the SDVO
LVDS code is doing by hand. Let's just call
intel_panel_edid_fixed_mode().
The slight difference in behaviour is that the SDVO code currently
bails if it can't find the preferred mode, whereas
intel_panel_edid_fixed_mode() will fall back to just returning
the first mode from the probed_modes list. Can't imagine why
such an LVDS panel would even exist, and also why would you have
a panel and be expected to not use it? So I'm going to assume
this is a total non-issue.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Apart from the EDID and VBT based mechanism we also sometimes
use the encoder's current mode as the panel fixed mode. We
currently have the same code for that duplicated in two places.
Let's unify.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Rename intel_panel_vbt_fixed_mode() to
intel_panel_vbt_lfp_fixed_mode() to be more descriptive.
We'll have another VBT fixed mode function soon and we
don't want to confuse the two.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Use intel_panel_preferred_fixed_mode() for all the orientation
quirk setup and compute_is_dual_link_lvds()). All of these
happen after intel_panel_init() so the panel fixed_mode list
is already in place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pull the drm_connector_set_panel_orientation_with_quirk()
into intel_edp_add_properties() to match how the DSI encoders
do it. Less clutter in intel_edp_init_connector() overall.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Replace all drm_mode_debug_printmodeline() calls with
DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more
terse in places where we previously had a newline in the precedeing
drm_dbg_kms(), and avoids anything else sneaking in between the two
printk()s in all cases.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move most of the pipe+output CSC programming to the
.color_commit_noarm() hook which runs before vblank evasion.
Only PIPE_CSC_MODE (the arming register) needs to remain in
inside the critical section.
A test case that just updates the CTM in a loop produces
the following i915_update_info numbers on ilk (w/o lockdep):
old new
Updates: 10012 Updates: 10008
| |
1us |** 1us |**********
|************* |*************
4us |********* 4us |*
|* |**
16us | 16us |
| |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 1345ns Min update: 1268ns
Max update: 16672ns Max update: 15656ns
Average update: 3914ns Average update: 2185ns
Overruns > 100us: 0 Overruns > 100us: 0
And here is tgl (forced to update both pipe CSC and
output CSC, and with lockdep enabled):
old new
Updates: 10012 Updates: 10012
| |
1us | 1us |
| |
4us |* 4us |**
|** |**********
16us |************* 16us |*************
|* |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 5204ns Min update: 5176ns
Max update: 176038ns Max update: 186685ns
Average update: 23931ns Average update: 16654ns
Overruns > 250us: 0 Overruns > 250us: 0
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
To reduce the amount of registers written during the vblank evade
critical section let's also split the .color_commit() hook to
noarm+arm pair. The noarm hook runs before the vblank evasion
with the arm hook staying inside the critical section.
Just the framework here, actually moving stuff out into the noarm
hook will follow.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
All the skl+ scaler registers are suitably confined to their own
cachelines so we don't need the uncore.lock to globally serialize
access to these registers. We actually already dropped some of this
in commit 14ad15296d ("drm/i915: Make skl+ universal plane
registers unlocked") as the plane scaler enabling/reconfiguration
became lockless. So let's complete that and remove the rest of
the locks from the scaler programming as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
When reading a packet from a host-to-guest ring buffer, there is no
memory barrier between reading the write index (to see if there is
a packet to read) and reading the contents of the packet. The Hyper-V
host uses store-release when updating the write index to ensure that
writes of the packet data are completed first. On the guest side,
the processor can reorder and read the packet data before the write
index, and sometimes get stale packet data. Getting such stale packet
data has been observed in a reproducible case in a VM on ARM64.
Fix this by using virt_load_acquire() to read the write index,
ensuring that reads of the packet data cannot be reordered
before it. Preventing such reordering is logically correct, and
with this change, getting stale data can no longer be reproduced.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Link: https://lore.kernel.org/r/1648394710-33480-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
intel_drrs_enable() and intel_drrs_disable() were renamed to
intel_drrs_activate() and intel_drrs_deactivate() in commit
54903c7a6b ("drm/i915: s/enable/active/ for DRRS") and it is
causing warnings when generating the kernel documentation.
But as for a while DRRS has its own file, so here just let the tool
generate the documentation for all exported and documented functions
in intel_drrs.c.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325183832.146472-1-jose.souza@intel.com
- fix multipath hang when disk goes live over reconnect (Anton Eidelman)
- fix RCU hole that allowed for endless looping in multipath round robin
(Chris Leech)
- remove redundant assignment after left shift (Colin Ian King)
- add quirks for Samsung X5 SSDs (Monish Kumar R)
- fix the read-only state for zoned namespaces with unsupposed features
(Pankaj Raghav)
- use a private workqueue instead of the system workqueue in nvmet
(Sagi Grimberg)
- allow duplicate NSIDs for private namespaces (Sungup Moon)
- expose use_threaded_interrupts read-only in sysfs (Xin Hao)
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAmJCtbALHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYOFhBAAmf9O0reg+hbVe4cPK0fhQ1a4SUfFiOyDFadCAyeX
22B1dNROrwK+2txKsFWqR6cSwS/Kn16I+wl34/2rLw4nkSCqFt9fRTB57XRS3h+C
YNgo+rA7wkdYsQpeihwUbW5oXnkeYsQPxa0np/W9ab3YyR1xyrz5HmRE4VyX913W
Iu2p7x0zzt2qqYbuQADYhF3dnLk9DaLSzr9gy82Du0FnxiqBA0nxLBRpfpAPc6t6
jsKxJeBgkrrZbikyEU5MpSc+/9D5Hmpt9uTn2cuPsSGC3WndwE3TSknhf2aoW89j
/kRA/nBB2kmUfvhpwmgnz1YAqa8lYbJS68w0wRVxK6L2xCPCYabNTmh/rz8h3neF
kl45vQSpdI3ZBJAAZzPS75cMMVWkEf3/SmCDyr55bdpQnXHtAMuH1XSqnCIhEQiZ
w/DueDmuVyGXJSOnKvszy22c0CK0MekDgd7tF6IV7VvE1njNo7elMGc16mkjb01A
XqHzYSAbv+pPsp91j9i3PxvB9CSv216+1lIhM8ZPTw2kLu3ROZo57qjMRsHYCTUn
1Hu5u3050ATQm9vmUc/K2fYUejxCgD5ALiEa/9OZxrHycW3PD921rIV+mswi1/tW
Qd2rXf+f8piMD8El6wFo/af5tcfcHwVtNEripWnGbMaThg1dkfCp99sG/GwkA3jH
Y48=
=O0yB
-----END PGP SIGNATURE-----
Merge tag 'nvme-5.18-2022-03-29' of git://git.infradead.org/nvme into for-5.18/drivers
Pull NVMe fixes from Christoph:
"- fix multipath hang when disk goes live over reconnect (Anton Eidelman)
- fix RCU hole that allowed for endless looping in multipath round robin
(Chris Leech)
- remove redundant assignment after left shift (Colin Ian King)
- add quirks for Samsung X5 SSDs (Monish Kumar R)
- fix the read-only state for zoned namespaces with unsupposed features
(Pankaj Raghav)
- use a private workqueue instead of the system workqueue in nvmet
(Sagi Grimberg)
- allow duplicate NSIDs for private namespaces (Sungup Moon)
- expose use_threaded_interrupts read-only in sysfs (Xin Hao)"
* tag 'nvme-5.18-2022-03-29' of git://git.infradead.org/nvme:
nvme-multipath: fix hang when disk goes live over reconnect
nvme: fix RCU hole that allowed for endless looping in multipath round robin
nvme: allow duplicate NSIDs for private namespaces
nvmet: remove redundant assignment after left shift
nvmet: use a private workqueue instead of the system workqueue
nvme-pci: add quirks for Samsung X5 SSDs
nvme-pci: expose use_threaded_interrupts read-only in sysfs
nvme: fix the read-only state for zoned namespaces with unsupposed features
PCI pass-thru devices in a Hyper-V VM are represented as a VMBus
device and as a PCI device. The coherence of the VMbus device is
set based on the VMbus node in ACPI, but the PCI device has no
ACPI node and defaults to not hardware coherent. This results
in extra software coherence management overhead on ARM64 when
devices are hardware coherent.
Fix this by setting up the PCI host bus so that normal
PCI mechanisms will propagate the coherence of the VMbus
device to the PCI device. There's no effect on x86/x64 where
devices are always hardware coherent.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Acked-by: Boqun Feng <boqun.feng@gmail.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/1648138492-2191-3-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
VMbus synthetic devices are not represented in the ACPI DSDT -- only
the top level VMbus device is represented. As a result, on ARM64
coherence information in the _CCA method is not specified for
synthetic devices, so they default to not hardware coherent.
Drivers for some of these synthetic devices have been recently
updated to use the standard DMA APIs, and they are incurring extra
overhead of unneeded software coherence management.
Fix this by propagating coherence information from the VMbus node
in ACPI to the individual synthetic devices. There's no effect on
x86/x64 where devices are always hardware coherent.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/1648138492-2191-2-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
The vmbus driver relies on the panic notifier infrastructure to perform
some operations when a panic event is detected. Since vmbus can be built
as module, it is required that the driver handles both registering and
unregistering such panic notifier callback.
After commit 74347a99e7 ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
though, the panic notifier registration is done unconditionally in the module
initialization routine whereas the unregistering procedure is conditionally
guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability
is set.
This patch fixes that by unconditionally unregistering the panic notifier
in the module's exit routine as well.
Fixes: 74347a99e7 ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220315203535.682306-1-gpiccoli@igalia.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
hv_panic_page might contain guest-sensitive information, do not dump it
over to Hyper-V by default in isolated guests.
While at it, update some comments in hyperv_{panic,die}_event().
Reported-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Dexuan Cui <decui@microsoft.com>
Link: https://lore.kernel.org/r/20220301141135.2232-1-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
