Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 1月, 2015 1 次提交
    • M
      ARM: OMAP: Work around hardcoded interrupts · 0fb22a8f
      由 Marc Zyngier 提交于 
      Commit 9a1091ef ("irqchip: gic: Support hierarchy irq domain")
changed the GIC driver to use a non-legacy IRQ domain on DT
platforms. This patch assumes that DT-driven systems are getting
all of their interrupts from device tree.

Turns out that OMAP has quite a few hidden gems, and still uses
hardcoded interrupts despite having fairly complete DTs.

This patch attempts to work around these by offering a translation
method that can be called directly from the hwmod code, if present.
The same hack is sprinkled over PRCM and TWL.

It isn't pretty, but it seems to do the job without having to add
more hacks to the interrupt controller code.

Tested on OMAP4 (Panda-ES) and OMAP5 (UEVM5432).
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Acked-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: updated to fix make randconfig issue]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      0fb22a8f
  3. 16 1月, 2015 1 次提交
  5. 07 1月, 2015 1 次提交
  7. 06 1月, 2015 6 次提交
  9. 20 12月, 2014 15 次提交
  11. 19 12月, 2014 2 次提交
  13. 18 12月, 2014 12 次提交
  15. 17 12月, 2014 2 次提交
    • S
      KVM: PPC: Book3S HV: Improve H_CONFER implementation · 90fd09f8
      由 Sam Bobroff 提交于 
      Currently the H_CONFER hcall is implemented in kernel virtual mode,
meaning that whenever a guest thread does an H_CONFER, all the threads
in that virtual core have to exit the guest.  This is bad for
performance because it interrupts the other threads even if they
are doing useful work.

The H_CONFER hcall is called by a guest VCPU when it is spinning on a
spinlock and it detects that the spinlock is held by a guest VCPU that
is currently not running on a physical CPU.  The idea is to give this
VCPU's time slice to the holder VCPU so that it can make progress
towards releasing the lock.

To avoid having the other threads exit the guest unnecessarily,
we add a real-mode implementation of H_CONFER that checks whether
the other threads are doing anything.  If all the other threads
are idle (i.e. in H_CEDE) or trying to confer (i.e. in H_CONFER),
it returns H_TOO_HARD which causes a guest exit and allows the
H_CONFER to be handled in virtual mode.

Otherwise it spins for a short time (up to 10 microseconds) to give
other threads the chance to observe that this thread is trying to
confer.  The spin loop also terminates when any thread exits the guest
or when all other threads are idle or trying to confer.  If the
timeout is reached, the H_CONFER returns H_SUCCESS.  In this case the
guest VCPU will recheck the spinlock word and most likely call
H_CONFER again.

This also improves the implementation of the H_CONFER virtual mode
handler.  If the VCPU is part of a virtual core (vcore) which is
runnable, there will be a 'runner' VCPU which has taken responsibility
for running the vcore.  In this case we yield to the runner VCPU
rather than the target VCPU.

We also introduce a check on the target VCPU's yield count: if it
differs from the yield count passed to H_CONFER, the target VCPU
has run since H_CONFER was called and may have already released
the lock.  This check is required by PAPR.
Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      90fd09f8
    • P
      KVM: PPC: Book3S HV: Fix endianness of instruction obtained from HEIR register · 4a157d61
      由 Paul Mackerras 提交于 
      There are two ways in which a guest instruction can be obtained from
the guest in the guest exit code in book3s_hv_rmhandlers.S.  If the
exit was caused by a Hypervisor Emulation interrupt (i.e. an illegal
instruction), the offending instruction is in the HEIR register
(Hypervisor Emulation Instruction Register).  If the exit was caused
by a load or store to an emulated MMIO device, we load the instruction
from the guest by turning data relocation on and loading the instruction
with an lwz instruction.

Unfortunately, in the case where the guest has opposite endianness to
the host, these two methods give results of different endianness, but
both get put into vcpu->arch.last_inst.  The HEIR value has been loaded
using guest endianness, whereas the lwz will load the instruction using
host endianness.  The rest of the code that uses vcpu->arch.last_inst
assumes it was loaded using host endianness.

To fix this, we define a new vcpu field to store the HEIR value.  Then,
in kvmppc_handle_exit_hv(), we transfer the value from this new field to
vcpu->arch.last_inst, doing a byte-swap if the guest and host endianness
differ.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      4a157d61