Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 12月, 2021 3 次提交
    • S
      KVM: arm64: Move vGIC v4 handling for WFI out arch callback hook · 6109c5a6
      由 Sean Christopherson 提交于 
      Move the put and reload of the vGIC out of the block/unblock callbacks
and into a dedicated WFI helper.  Functionally, this is nearly a nop as
the block hook is called at the very beginning of kvm_vcpu_block(), and
the only code in kvm_vcpu_block() after the unblock hook is to update the
halt-polling controls, i.e. can only affect the next WFI.

Back when the arch (un)blocking hooks were added by commits 3217f7c2
("KVM: Add kvm_arch_vcpu_{un}blocking callbacks) and d35268da
("arm/arm64: KVM: arch_timer: Only schedule soft timer on vcpu_block"),
the hooks were invoked only when KVM was about to "block", i.e. schedule
out the vCPU.  The use case at the time was to schedule a timer in the
host based on the earliest timer in the guest in order to wake the
blocking vCPU when the emulated guest timer fired.  Commit accb99bc
("KVM: arm/arm64: Simplify bg_timer programming") reworked the timer
logic to be even more precise, by waiting until the vCPU was actually
scheduled out, and so move the timer logic from the (un)blocking hooks to
vcpu_load/put.

In the meantime, the hooks gained usage for enabling vGIC v4 doorbells in
commit df9ba959 ("KVM: arm/arm64: GICv4: Use the doorbell interrupt
as an unblocking source"), and added related logic for the VMCR in commit
5eeaf10e ("KVM: arm/arm64: Sync ICH_VMCR_EL2 back when about to block").

Finally, commit 07ab0f8d ("KVM: Call kvm_arch_vcpu_blocking early
into the blocking sequence") hoisted the (un)blocking hooks so that they
wrapped KVM's halt-polling logic in addition to the core "block" logic.

In other words, the original need for arch hooks to take action _only_
in the block path is long since gone.

Cc: Oliver Upton <oupton@google.com>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Message-Id: <20211009021236.4122790-11-seanjc@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6109c5a6
    • M
      KVM: Use 'unsigned long' as kvm_for_each_vcpu()'s index · 46808a4c
      由 Marc Zyngier 提交于 
      Everywhere we use kvm_for_each_vpcu(), we use an int as the vcpu
index. Unfortunately, we're about to move rework the iterator,
which requires this to be upgrade to an unsigned long.

Let's bite the bullet and repaint all of it in one go.
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Message-Id: <20211116160403.4074052-7-maz@kernel.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      46808a4c
    • M
      KVM: Move wiping of the kvm->vcpus array to common code · 27592ae8
      由 Marc Zyngier 提交于 
      All architectures have similar loops iterating over the vcpus,
freeing one vcpu at a time, and eventually wiping the reference
off the vcpus array. They are also inconsistently taking
the kvm->lock mutex when wiping the references from the array.

Make this code common, which will simplify further changes.
The locking is dropped altogether, as this should only be called
when there is no further references on the kvm structure.
Reviewed-by: NClaudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Message-Id: <20211116160403.4074052-2-maz@kernel.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      27592ae8
  3. 18 11月, 2021 1 次提交
  5. 08 11月, 2021 1 次提交
  7. 17 10月, 2021 1 次提交
  9. 11 10月, 2021 5 次提交
  11. 01 10月, 2021 1 次提交
  13. 20 8月, 2021 2 次提交
  15. 19 8月, 2021 3 次提交
  17. 18 8月, 2021 3 次提交
  19. 11 8月, 2021 1 次提交
  21. 04 8月, 2021 1 次提交
  23. 30 7月, 2021 1 次提交
  25. 22 6月, 2021 2 次提交
  27. 18 6月, 2021 1 次提交
  29. 11 6月, 2021 1 次提交
  31. 27 5月, 2021 1 次提交
  33. 26 5月, 2021 1 次提交
    • F
      arm64: Rename arm64-internal cache maintenance functions · fade9c2c
      由 Fuad Tabba 提交于 
      Although naming across the codebase isn't that consistent, it
tends to follow certain patterns. Moreover, the term "flush"
isn't defined in the Arm Architecture reference manual, and might
be interpreted to mean clean, invalidate, or both for a cache.

Rename arm64-internal functions to make the naming internally
consistent, as well as making it consistent with the Arm ARM, by
specifying whether it applies to the instruction, data, or both
caches, whether the operation is a clean, invalidate, or both.
Also specify which point the operation applies to, i.e., to the
point of unification (PoU), coherency (PoC), or persistence
(PoP).

This commit applies the following sed transformation to all files
under arch/arm64:

"s/\b__flush_cache_range\b/caches_clean_inval_pou_macro/g;"\
"s/\b__flush_icache_range\b/caches_clean_inval_pou/g;"\
"s/\binvalidate_icache_range\b/icache_inval_pou/g;"\
"s/\b__flush_dcache_area\b/dcache_clean_inval_poc/g;"\
"s/\b__inval_dcache_area\b/dcache_inval_poc/g;"\
"s/__clean_dcache_area_poc\b/dcache_clean_poc/g;"\
"s/\b__clean_dcache_area_pop\b/dcache_clean_pop/g;"\
"s/\b__clean_dcache_area_pou\b/dcache_clean_pou/g;"\
"s/\b__flush_cache_user_range\b/caches_clean_inval_user_pou/g;"\
"s/\b__flush_icache_all\b/icache_inval_all_pou/g;"

Note that __clean_dcache_area_poc is deliberately missing a word
boundary check at the beginning in order to match the efistub
symbols in image-vars.h.

Also note that, despite its name, __flush_icache_range operates
on both instruction and data caches. The name change here
reflects that.

No functional change intended.
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NFuad Tabba <tabba@google.com>
Reviewed-by: NArd Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210524083001.2586635-19-tabba@google.comSigned-off-by: NWill Deacon <will@kernel.org>
      fade9c2c
  35. 15 5月, 2021 1 次提交
  37. 17 4月, 2021 2 次提交
  39. 07 4月, 2021 3 次提交
  41. 06 4月, 2021 1 次提交
  43. 31 3月, 2021 1 次提交
  45. 25 3月, 2021 1 次提交
  47. 19 3月, 2021 2 次提交