KVM:arm64: Proposed host stage-2 improvements
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest3 patches 1 replyIn review
- v13 patches 3 repliesSuperseded
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | KVM: arm64: Constraint KVM's own __flush_dcache_area to protectected modearch/ | +4 | 0 replies | |
| 2/3 | KVM: arm64: Generate final CTR_EL0 value when running in Protected modearch/ arch/ arch/ | +17 | 0 replies | |
| 3/3 | KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructurearch/ arch/ arch/ +6 more | +15 | 1 reply |
Reviews trailers per patch
1 of 3 patches has a Reviewed-by or Acked-by.
| Patch | Quentin Perret |
|---|---|
| 1/3 | |
| 2/3 | |
| 3/3 | R-b |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH v2 0/3] KVM:arm64: Proposed host stage-2 improvements
[apologies for the noise: this is the real thing, please ignore the previous posting... :-(]
Hi all,
Since Quentin's series is pretty close to final, I though that instead of asking for additional rework, I'd have a go at it myself. These patches try to bring some simplifications to the cpufeature duplication that has been introduced between EL1 and EL2.
This whole infrastructure exists for a single reason: making the *sanitised* versions of ID_AA64MMFR{0,1}_EL1 available to EL2. On top of that, the read_ctr macro gets in the way as it needs direct access to arm64_ftr_reg_ctrel0 to cope with ARM64_MISMATCHED_CACHE_TYPE.
This series tackles the latest point first by taking advantage of the fact that with pKVM enabled, late CPUs aren't allowed to boot, and thus that we know the final CTR_EL0 value before KVM starts, no matter whether there is a mismatch or not. We can thus specialise read_ctr to do the right thing without requiring access to the EL1 data structure.
Once that's sorted, we can easily simplify the whole infrastructure to only snapshot the two u64 we need before enabling the protected mode.
Tested on a Synquacer system.
M.
* From v1:
- Send the *right* branch, and not whatever was in my sandbox...
Marc Zyngier (3):
KVM: arm64: Constraint KVM's own __flush_dcache_area to protectected
mode
KVM: arm64: Generate final CTR_EL0 value when running in Protected
mode
KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure
arch/arm64/include/asm/assembler.h | 9 +++++++++ arch/arm64/include/asm/cpufeature.h | 1 - arch/arm64/include/asm/kvm_cpufeature.h | 26 ------------------------- arch/arm64/include/asm/kvm_host.h | 4 ---- arch/arm64/include/asm/kvm_hyp.h | 3 +++ arch/arm64/kernel/cpufeature.c | 13 ------------- arch/arm64/kernel/image-vars.h | 1 + arch/arm64/kvm/arm.c | 3 +++ arch/arm64/kvm/hyp/nvhe/cache.S | 4 ++++ arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 8 -------- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 16 ++++++++------- arch/arm64/kvm/sys_regs.c | 22 --------------------- arch/arm64/kvm/va_layout.c | 7 +++++++ 13 files changed, 36 insertions(+), 81 deletions(-) delete mode 100644 arch/arm64/include/asm/kvm_cpufeature.h
Signature · 6 lines
2.29.2 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm