linux-stable.git/drivers/irqchip, branch v5.8

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2020-07-06T19:48:04+00:00

Pull kvm fixes from Paolo Bonzini:
 "Bugfixes and a one-liner patch to silence a sparse warning"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: arm64: Stop clobbering x0 for HVC_SOFT_RESTART
  KVM: arm64: PMU: Fix per-CPU access in preemptible context
  KVM: VMX: Use KVM_POSSIBLE_CR*_GUEST_BITS to initialize guest/host masks
  KVM: x86: Mark CR4.TSD as being possibly owned by the guest
  KVM: x86: Inject #GP if guest attempts to toggle CR4.LA57 in 64-bit mode
  kvm: use more precise cast and do not drop __user
  KVM: x86: bit 8 of non-leaf PDPEs is not reserved
  KVM: X86: Fix async pf caused null-ptr-deref
  KVM: arm64: vgic-v4: Plug race between non-residency and v4.1 doorbell
  KVM: arm64: pvtime: Ensure task delay accounting is enabled
  KVM: arm64: Fix kvm_reset_vcpu() return code being incorrect with SVE
  KVM: arm64: Annotate hyp NMI-related functions as __always_inline
  KVM: s390: reduce number of IO pins to 1

KVM: arm64: vgic-v4: Plug race between non-residency and v4.1 doorbell

2020-06-23T10:24:39+00:00

When making a vPE non-resident because it has hit a blocking WFI,
the doorbell can fire at any time after the write to the RD.
Crucially, it can fire right between the write to GICR_VPENDBASER
and the write to the pending_last field in the its_vpe structure.

This means that we would overwrite pending_last with stale data,
and potentially not wakeup until some unrelated event (such as
a timer interrupt) puts the vPE back on the CPU.

GICv4 isn't affected by this as we actively mask the doorbell on
entering the guest, while GICv4.1 automatically manages doorbell
delivery without any hypervisor-driven masking.

Use the vpe_lock to synchronize such update, which solves the
problem altogether.

Fixes: ae699ad348cdc ("irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer")
Reported-by: Zenghui Yu 
Signed-off-by: Marc Zyngier

irqchip/gic: Atomically update affinity

2020-06-21T14:24:46+00:00

The GIC driver uses a RMW sequence to update the affinity, and
relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences
to update it atomically.

But these sequences only expand into anything meaningful if
the BL_SWITCHER option is selected, which almost never happens.

It also turns out that using a RMW and locks is just as silly,
as the GIC distributor supports byte accesses for the GICD_TARGETRn
registers, which when used make the update atomic by definition.

Drop the terminally broken code and replace it by a byte write.

Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier

irqchip/riscv-intc: Fix a typo in a pr_warn()

2020-06-21T14:15:41+00:00

Anup originally re-spun his patch set to include this fix, but it was a bit too
late for my PR so I've split it out.

Signed-off-by: Palmer Dabbelt 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200611175302.253540-1-palmer@dabbelt.com

irqchip/gic-v4.1: Use readx_poll_timeout_atomic() to fix sleep in atomic

2020-06-21T14:13:11+00:00

readx_poll_timeout() can sleep if @sleep_us is specified by the caller,
and is therefore unsafe to be used inside the atomic context, which is
this case when we use it to poll the GICR_VPENDBASER.Dirty bit in
irq_set_vcpu_affinity() callback.

Let's convert to its atomic version instead which helps to get the v4.1
board back to life!

Fixes: 96806229ca03 ("irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling")
Signed-off-by: Zenghui Yu 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200605052345.1494-1-yuzenghui@huawei.com

irqchip/loongson-pci-msi: Fix a typo in Kconfig

2020-06-21T14:13:11+00:00

PCH MSI driver's menuconfig entry was wrong. Fix it.

Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller")
Signed-off-by: Jiaxun Yang 
Signed-off-by: Marc Zyngier 
Link: https://lore.kernel.org/r/20200530121113.1797678-2-jiaxun.yang@flygoat.com

clocksource/drivers/timer-riscv: Use per-CPU timer interrupt

2020-06-10T02:11:22+00:00

Instead of directly calling RISC-V timer interrupt handler from
RISC-V local interrupt conntroller driver, this patch implements
RISC-V timer interrupt as a per-CPU interrupt using per-CPU APIs
of Linux IRQ subsystem.

Signed-off-by: Anup Patel 
Reviewed-by: Atish Patra 
Reviewed-by: Marc Zyngier 
Signed-off-by: Palmer Dabbelt

irqchip: RISC-V per-HART local interrupt controller driver

2020-06-10T02:11:21+00:00

The RISC-V per-HART local interrupt controller manages software
interrupts, timer interrupts, external interrupts (which are routed
via the platform level interrupt controller) and other per-HART
local interrupts.

We add a driver for the RISC-V local interrupt controller, which
eventually replaces the RISC-V architecture code, allowing for a
better split between arch code and drivers.

The driver is compliant with RISC-V Hart-Level Interrupt Controller
DT bindings located at:
Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt

Co-developed-by: Palmer Dabbelt 
Signed-off-by: Anup Patel 
[Palmer: Cleaned up warnings]
Signed-off-by: Palmer Dabbelt

RISC-V: Rename and move plic_find_hart_id() to arch directory

2020-06-10T02:11:20+00:00

The plic_find_hart_id() can be useful to other interrupt controller
drivers (such as RISC-V local interrupt driver) so we rename this
function to riscv_of_parent_hartid() and place it in arch directory
along with riscv_of_processor_hartid().

Signed-off-by: Anup Patel 
Reviewed-by: Atish Patra 
Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt 
Reviewed-by: Marc Zyngier 
Signed-off-by: Palmer Dabbelt

irqchip: Fix "Loongson HyperTransport Vector support" driver build on all non-MIPS platforms

2020-06-01T07:48:52+00:00

This commit:

  818e915fbac5: ("irqchip: Add Loongson HyperTransport Vector support")

Added a MIPS-only driver, but turned on compilation on all other architectures as well:

 config LOONGSON_HTVEC
        bool "Loongson3 HyperTransport Interrupt Vector Controller"
        depends on MACH_LOONGSON64 || COMPILE_TEST

But this driver was never build tested on any other architecture than MIPS:

  drivers/irqchip/irq-loongson-htvec.c: In function ‘htvec_irq_dispatch’:
  drivers/irqchip/irq-loongson-htvec.c:59:3: error: implicit declaration of function ‘spurious_interrupt’; did you mean ‘smp_reboot_interrupt’? [-Werror=implicit-function-declaration]

Because spurious_interrupt() only exists on MIPS.

So make it MIPS-only.

Signed-off-by: Ingo Molnar 
Cc: Jiaxun Yang 
Cc: Marc Zyngier 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar