KVM/arm64 fixes for 5.9
Subsystems (7)
Marc Zyngier
maintainerHi Paolo,
Here's a bunch of fixes for 5.9. The gist of it is the stolen time rework from Andrew, but we also have a couple of MM fixes that have surfaced as people have started to use hugetlbfs in anger.
Please pull,
M.
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-5.9-1
for you to fetch changes up to 7b75cd5128421c673153efb1236705696a1a9812:
KVM: arm64: Update page shift if stage 2 block mapping not supported (2020-09-04 10:53:48 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for Linux 5.9, take #1
- Multiple stolen time fixes, with a new capability to match x86
- Fix for hugetlbfs mappings when PUD and PMD are the same level
- Fix for hugetlbfs mappings when PTE mappings are enforced (dirty logging, for example)
- Fix tracing output of 64bit values
----------------------------------------------------------------
Alexandru Elisei (1):
KVM: arm64: Update page shift if stage 2 block mapping not supported
Andrew Jones (6):
KVM: arm64: pvtime: steal-time is only supported when configured
KVM: arm64: pvtime: Fix potential loss of stolen time
KVM: arm64: Drop type input from kvm_put_guest
KVM: arm64: pvtime: Fix stolen time accounting across migration
KVM: Documentation: Minor fixups
arm64/x86: KVM: Introduce steal-time cap
Marc Zyngier (2):
KVM: arm64: Do not try to map PUDs when they are folded into PMD
KVM: arm64: Fix address truncation in traces
Documentation/virt/kvm/api.rst | 22 ++++++++++++++++++---- arch/arm64/include/asm/kvm_host.h | 2 +- arch/arm64/kvm/arm.c | 3 +++ arch/arm64/kvm/mmu.c | 8 +++++++- arch/arm64/kvm/pvtime.c | 29 +++++++++++++---------------- arch/arm64/kvm/trace_arm.h | 16 ++++++++-------- arch/arm64/kvm/trace_handle_exit.h | 6 +++--- arch/x86/kvm/x86.c | 3 +++ include/linux/kvm_host.h | 31 ++++++++++++++++++++++++++----- include/uapi/linux/kvm.h | 1 + 10 files changed, 83 insertions(+), 38 deletions(-)
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 1/9 KVM: arm64: pvtime: steal-time is only supported when configured
From: Andrew Jones <[email protected]>
Don't confuse the guest by saying steal-time is supported when it hasn't been configured by userspace and won't work.
--- arch/arm64/kvm/pvtime.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/arm64/kvm/pvtime.c +2 -1
@@ -43,7 +43,8 @@ long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu)switch (feature) {case ARM_SMCCC_HV_PV_TIME_FEATURES :case ARM_SMCCC_HV_PV_TIME_ST : - val =SMCCC_RET_SUCCESS ; +if (vcpu->arch.steal.base !=GPA_INVALID ) + val =SMCCC_RET_SUCCESS ;break ; }
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 2/9 KVM: arm64: pvtime: Fix potential loss of stolen time
In reply to Marc ZyngierFrom: Andrew Jones <[email protected]>
We should only check current->sched_info.run_delay once when updating stolen time. Otherwise there's a chance there could be a change between checks that we miss (preemption disabling comes after vcpu request checks).
--- arch/arm64/kvm/pvtime.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/arm64/kvm/pvtime.c +3 -2
@@ -13,6 +13,7 @@void kvm_update_stolen_time (struct kvm_vcpu *vcpu) {struct kvm *kvm = vcpu->kvm; +u64 last_steal = vcpu->arch.steal.last_steal;u64 steal;__le64 steal_le;u64 offset;
@@ -24,8 +25,8 @@ void kvm_update_stolen_time(struct kvm_vcpu *vcpu)/* Let's do the local bookkeeping */ steal = vcpu->arch.steal.steal; - steal += current->sched_info.run_delay - vcpu->arch.steal.last_steal; - vcpu->arch.steal.last_steal = current->sched_info.run_delay; + vcpu->arch.steal.last_steal =READ_ONCE (current->sched_info.run_delay); + steal += vcpu->arch.steal.last_steal - last_steal; vcpu->arch.steal.steal = steal; steal_le =cpu_to_le64 (steal);
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 3/9 KVM: arm64: Drop type input from kvm_put_guest
In reply to Marc ZyngierFrom: Andrew Jones <[email protected]>
We can use typeof() to avoid the need for the type input.
--- arch/arm64/kvm/pvtime.c | 2 +- include/linux/kvm_host.h | 11 ++++++----- 2 files changed, 7 insertions(+), 6 deletions(-)
arch/arm64/kvm/pvtime.c +1 -1
@@ -32,7 +32,7 @@ void kvm_update_stolen_time(struct kvm_vcpu *vcpu) steal_le =cpu_to_le64 (steal); idx =srcu_read_lock (&kvm->srcu); offset = offsetof(struct pvclock_vcpu_stolen_time , stolen_time); -kvm_put_guest (kvm, base + offset, steal_le, u64); +kvm_put_guest (kvm, base + offset, steal_le);srcu_read_unlock (&kvm->srcu, idx); }
include/linux/kvm_host.h +6 -5
@@ -749,25 +749,26 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,int kvm_gfn_to_hva_cache_init (struct kvm *kvm,struct gfn_to_hva_cache *ghc,gpa_t gpa,unsigned long len); -#define __kvm_put_guest (kvm, gfn, offset, value, type) \ +#define __kvm_put_guest (kvm, gfn, offset, v) \ ({ \ unsigned long __addr = gfn_to_hva(kvm, gfn); \ - type __user *__uaddr = (type __user *)(__addr + offset); \ + typeof(v) __user *__uaddr = (typeof(__uaddr))(__addr + offset); \ int __ret = -EFAULT; \ \ if (!kvm_is_error_hva(__addr)) \ - __ret = put_user(value, __uaddr); \ + __ret = put_user(v, __uaddr); \ if (!__ret) \ mark_page_dirty(kvm, gfn); \ __ret; \ }) -#define kvm_put_guest (kvm, gpa, value, type) \ +#define kvm_put_guest (kvm, gpa, v) \ ({ \ gpa_t __gpa = gpa; \ struct kvm *__kvm = kvm; \ + \ __kvm_put_guest(__kvm, __gpa >> PAGE_SHIFT, \ - offset_in_page(__gpa), (value), type); \ + offset_in_page(__gpa), v); \ })int kvm_clear_guest_page (struct kvm *kvm,gfn_t gfn,int offset,int len);
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 4/9 KVM: arm64: pvtime: Fix stolen time accounting across migration
In reply to Marc ZyngierFrom: Andrew Jones <[email protected]>
When updating the stolen time we should always read the current stolen time from the user provided memory, not from a kernel cache. If we use a cache then we'll end up resetting stolen time to zero on the first update after migration.
--- arch/arm64/include/asm/kvm_host.h | 1 - arch/arm64/kvm/pvtime.c | 23 +++++++++-------------- include/linux/kvm_host.h | 20 ++++++++++++++++++++ 3 files changed, 29 insertions(+), 15 deletions(-)
arch/arm64/include/asm/kvm_host.h +0 -1
@@ -368,7 +368,6 @@ struct kvm_vcpu_arch {/* Guest PV state */ struct { -u64 steal;u64 last_steal;gpa_t base; } steal;
arch/arm64/kvm/pvtime.c +9 -14
@@ -13,26 +13,22 @@void kvm_update_stolen_time (struct kvm_vcpu *vcpu) {struct kvm *kvm = vcpu->kvm; +u64 base = vcpu->arch.steal.base;u64 last_steal = vcpu->arch.steal.last_steal; -u64 steal; -__le64 steal_le; -u64 offset; +u64 offset = offsetof(struct pvclock_vcpu_stolen_time , stolen_time); +u64 steal =0 ;int idx; -u64 base = vcpu->arch.steal.base;if (base ==GPA_INVALID )return ; -/* Let's do the local bookkeeping */ - steal = vcpu->arch.steal.steal; - vcpu->arch.steal.last_steal =READ_ONCE (current->sched_info.run_delay); - steal += vcpu->arch.steal.last_steal - last_steal; - vcpu->arch.steal.steal = steal; - - steal_le =cpu_to_le64 (steal); idx =srcu_read_lock (&kvm->srcu); - offset = offsetof(struct pvclock_vcpu_stolen_time , stolen_time); -kvm_put_guest (kvm, base + offset, steal_le); +if (!kvm_get_guest (kvm, base + offset, steal)) { + steal =le64_to_cpu (steal); + vcpu->arch.steal.last_steal =READ_ONCE (current->sched_info.run_delay); + steal += vcpu->arch.steal.last_steal - last_steal; +kvm_put_guest (kvm, base + offset,cpu_to_le64 (steal)); + }srcu_read_unlock (&kvm->srcu, idx); }
@@ -66,7 +62,6 @@ gpa_t kvm_init_stolen_time(struct kvm_vcpu *vcpu)* Start counting stolen time from the time the guest requests * the feature enabled. */ - vcpu->arch.steal.steal =0 ; vcpu->arch.steal.last_steal = current->sched_info.run_delay; idx =srcu_read_lock (&kvm->srcu);
include/linux/kvm_host.h +20 -0
@@ -749,6 +749,26 @@ int kvm_write_guest_offset_cached(struct kvm *kvm, struct gfn_to_hva_cache *ghc,int kvm_gfn_to_hva_cache_init (struct kvm *kvm,struct gfn_to_hva_cache *ghc,gpa_t gpa,unsigned long len); +#define __kvm_get_guest (kvm, gfn, offset, v) \ +({ \ + unsigned long __addr = gfn_to_hva(kvm, gfn); \ + typeof(v) __user *__uaddr = (typeof(__uaddr))(__addr + offset); \ + int __ret = -EFAULT; \ + \ + if (!kvm_is_error_hva(__addr)) \ + __ret = get_user(v, __uaddr); \ + __ret; \ +}) + +#define kvm_get_guest (kvm, gpa, v) \ +({ \ + gpa_t __gpa = gpa; \ + struct kvm *__kvm = kvm; \ + \ + __kvm_get_guest(__kvm, __gpa >> PAGE_SHIFT, \ + offset_in_page(__gpa), v); \ +}) +#define __kvm_put_guest (kvm, gfn, offset, v) \ ({ \ unsigned long __addr = gfn_to_hva(kvm, gfn); \
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 5/9 KVM: Documentation: Minor fixups
In reply to Marc ZyngierFrom: Andrew Jones <[email protected]>
In preparation for documenting a new capability let's fix up the formatting of the current ones.
--- Documentation/virt/kvm/api.rst | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
Documentation/virt/kvm/api.rst +5 -4
@@ -6130,7 +6130,7 @@ HvCallSendSyntheticClusterIpi, HvCallSendSyntheticClusterIpiEx. 8.21 KVM_CAP_HYPERV_DIRECT_TLBFLUSH ----------------------------------- -:Architecture: x86 +:Architectures: x86 This capability indicates that KVM running on top of Hyper-V hypervisor enables Direct TLB flush for its guests meaning that TLB flush
@@ -6143,16 +6143,17 @@ in CPUID and only exposes Hyper-V identification. In this case, guest thinks it's running on Hyper-V and only use Hyper-V hypercalls. 8.22 KVM_CAP_S390_VCPU_RESETS +----------------------------- -Architectures: s390 +:Architectures: s390 This capability indicates that the KVM_S390_NORMAL_RESET and KVM_S390_CLEAR_RESET ioctls are available. 8.23 KVM_CAP_S390_PROTECTED +--------------------------- -Architecture: s390 - +:Architectures: s390 This capability indicates that the Ultravisor has been initialized and KVM can therefore start protected VMs.
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 6/9 arm64/x86: KVM: Introduce steal-time cap
In reply to Marc ZyngierFrom: Andrew Jones <[email protected]>
arm64 requires a vcpu fd (KVM_HAS_DEVICE_ATTR vcpu ioctl) to probe support for steal-time. However this is unnecessary, as only a KVM fd is required, and it complicates userspace (userspace may prefer delaying vcpu creation until after feature probing). Introduce a cap that can be checked instead. While x86 can already probe steal-time support with a kvm fd (KVM_GET_SUPPORTED_CPUID), we add the cap there too for consistency.
--- Documentation/virt/kvm/api.rst | 13 +++++++++++++ arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/kvm/arm.c | 3 +++ arch/arm64/kvm/pvtime.c | 2 +- arch/x86/kvm/x86.c | 3 +++ include/uapi/linux/kvm.h | 1 + 6 files changed, 22 insertions(+), 1 deletion(-)
Documentation/virt/kvm/api.rst +13 -0
@@ -6160,3 +6160,16 @@ KVM can therefore start protected VMs. This capability governs the KVM_S390_PV_COMMAND ioctl and the KVM_MP_STATE_LOAD MP_STATE. KVM_SET_MP_STATE can fail for protected guests when the state change is invalid. + +8.24 KVM_CAP_STEAL_TIME +----------------------- + +:Architectures: arm64, x86 + +This capability indicates that KVM supports steal time accounting. +When steal time accounting is supported it may be enabled with +architecture-specific interfaces. This capability and the architecture- +specific interfaces must be consistent, i.e. if one says the feature +is supported, than the other should as well and vice versa. For arm64 +see Documentation/virt/kvm/devices/vcpu.rst "KVM_ARM_VCPU_PVTIME_CTRL". +For x86 see Documentation/virt/kvm/msr.rst "MSR_KVM_STEAL_TIME".
arch/arm64/include/asm/kvm_host.h +1 -0
@@ -543,6 +543,7 @@ long kvm_hypercall_pv_features(struct kvm_vcpu *vcpu);gpa_t kvm_init_stolen_time (struct kvm_vcpu *vcpu);void kvm_update_stolen_time (struct kvm_vcpu *vcpu); +bool kvm_arm_pvtime_supported (void );int kvm_arm_pvtime_set_attr (struct kvm_vcpu *vcpu,struct kvm_device_attr *attr); int kvm_arm_pvtime_get_attr(struct kvm_vcpu *vcpu,
arch/arm64/kvm/arm.c +3 -0
@@ -206,6 +206,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)*/ r =1 ;break ; +case KVM_CAP_STEAL_TIME : + r =kvm_arm_pvtime_supported (); +break ;default : r =kvm_arch_vm_ioctl_check_extension (kvm, ext);break ;
arch/arm64/kvm/pvtime.c +1 -1
@@ -71,7 +71,7 @@ gpa_t kvm_init_stolen_time(struct kvm_vcpu *vcpu)return base; } -static bool kvm_arm_pvtime_supported (void ) +bool kvm_arm_pvtime_supported (void ) {return !!sched_info_on (); }
arch/x86/kvm/x86.c +3 -0
@@ -3581,6 +3581,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)case KVM_CAP_SMALLER_MAXPHYADDR : r = (int ) allow_smaller_maxphyaddr;break ; +case KVM_CAP_STEAL_TIME : + r =sched_info_on (); +break ;default :break ; }
include/uapi/linux/kvm.h +1 -0
@@ -1035,6 +1035,7 @@ struct kvm_ppc_resize_hpt {#define KVM_CAP_LAST_CPU 184#define KVM_CAP_SMALLER_MAXPHYADDR 185#define KVM_CAP_S390_DIAG318 186 +#define KVM_CAP_STEAL_TIME 187#ifdef KVM_CAP_IRQ_ROUTING
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 7/9 KVM: arm64: Do not try to map PUDs when they are folded into PMD
In reply to Marc ZyngierFor the obscure cases where PMD and PUD are the same size (64kB pages with 42bit VA, for example, which results in only two levels of page tables), we can't map anything as a PUD, because there is... erm... no PUD to speak of. Everything is either a PMD or a PTE.
So let's only try and map a PUD when its size is different from that of a PMD.
--- arch/arm64/kvm/mmu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
arch/arm64/kvm/mmu.c +6 -1
@@ -1964,7 +1964,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, (fault_status ==FSC_PERM &&stage2_is_exec (mmu, fault_ipa, vma_pagesize)); -if (vma_pagesize ==PUD_SIZE ) { +/* +* If PUD_SIZE == PMD_SIZE, there is no real PUD level, and +* all we have is a 2-level page table. Trying to map a PUD in +* this case would be fatally wrong. +*/ +if (PUD_SIZE !=PMD_SIZE && vma_pagesize ==PUD_SIZE ) {pud_t new_pud =kvm_pfn_pud (pfn, mem_type); new_pud =kvm_pud_mkhuge (new_pud);
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH 7/9] KVM: arm64: Do not try to map PUDs when they are folded into PMD
Hi Marc,
Noticed this patch while catching up with the lists.
Quoted 31 lines · Marc Zyngier
For the obscure cases where PMD and PUD are the same size (64kB pages with 42bit VA, for example, which results in only two levels of page tables), we can't map anything as a PUD, because there is... erm... no PUD to speak of. Everything is either a PMD or a PTE.
So let's only try and map a PUD when its size is different from that of a PMD.
Fixes b8e0ba7c8bea ("KVM: arm64: Add support for creating PUD hugepages at stage 2")Reported-by Gavin Shan <[email protected]>Reported-by Eric Auger <[email protected]>Reviewed-by Alexandru Elisei <[email protected]>Reviewed-by Gavin Shan <[email protected]>Tested-by Gavin Shan <[email protected]>Tested-by Eric Auger <[email protected]>Tested-by Alexandru Elisei <[email protected]>Signed-off-by Marc Zyngier <[email protected]>--- arch/arm64/kvm/mmu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)arch/arm64/kvm/mmu.c +0
-0@@ -1964,7 +1964,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, (fault_status ==FSC_PERM &&stage2_is_exec (mmu, fault_ipa, vma_pagesize));
arch/arm64/kvm/mmu.c static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, · line 1975
Quoted 10 lines
arch/arm64/kvm/mmu.c +6
-1-if (vma_pagesize ==PUD_SIZE ) { +/* +* If PUD_SIZE == PMD_SIZE, there is no real PUD level, and +* all we have is a 2-level page table. Trying to map a PUD in +* this case would be fatally wrong. +*/ +if (PUD_SIZE !=PMD_SIZE && vma_pagesize ==PUD_SIZE ) {pud_t new_pud =kvm_pfn_pud (pfn, mem_type); new_pud =kvm_pud_mkhuge (new_pud);
Good catch!
Missed the 64kb / 42b VA case while adding the initial support.
Thanks for fixing it.
Punit
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Marc Zyngier
maintainerPATCH 8/9 KVM: arm64: Fix address truncation in traces
In reply to Marc ZyngierOwing to their ARMv7 origins, the trace events are truncating most address values to 32bits. That's not really helpful.
Expand the printing of such values to their full glory.
--- arch/arm64/kvm/trace_arm.h | 16 ++++++++-------- arch/arm64/kvm/trace_handle_exit.h | 6 +++--- 2 files changed, 11 insertions(+), 11 deletions(-)
arch/arm64/kvm/trace_arm.h +8 -8
@@ -23,7 +23,7 @@ TRACE_EVENT(kvm_entry, __entry->vcpu_pc = vcpu_pc; ), -TP_printk ("PC: 0x%08lx" , __entry->vcpu_pc) +TP_printk ("PC: 0x%016lx" , __entry->vcpu_pc) ); TRACE_EVENT(kvm_exit,
@@ -42,7 +42,7 @@ TRACE_EVENT(kvm_exit, __entry->vcpu_pc = vcpu_pc; ), - TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%08lx", + TP_printk("%s: HSR_EC: 0x%04x (%s), PC: 0x%016lx", __print_symbolic(__entry->ret, kvm_arm_exception_type), __entry->esr_ec, __print_symbolic(__entry->esr_ec, kvm_arm_exception_class),
@@ -69,7 +69,7 @@ TRACE_EVENT(kvm_guest_fault, __entry->ipa = ipa; ), -TP_printk ("ipa %#llx, hsr %#08lx, hxfar %#08lx, pc %#08lx" , +TP_printk ("ipa %#llx, hsr %#08lx, hxfar %#08lx, pc %#016lx" , __entry->ipa, __entry->hsr, __entry->hxfar, __entry->vcpu_pc) );
@@ -131,7 +131,7 @@ TRACE_EVENT(kvm_mmio_emulate, __entry->cpsr = cpsr; ), -TP_printk ("Emulate MMIO at: 0x%08lx (instr: %08lx, cpsr: %08lx)" , +TP_printk ("Emulate MMIO at: 0x%016lx (instr: %08lx, cpsr: %08lx)" , __entry->vcpu_pc, __entry->instr, __entry->cpsr) );
@@ -149,7 +149,7 @@ TRACE_EVENT(kvm_unmap_hva_range, __entry->end = end; ), -TP_printk ("mmu notifier unmap range: %#08lx -- %#08lx" , +TP_printk ("mmu notifier unmap range: %#016lx -- %#016lx" , __entry->start, __entry->end) );
@@ -165,7 +165,7 @@ TRACE_EVENT(kvm_set_spte_hva, __entry->hva = hva; ), -TP_printk ("mmu notifier set pte hva: %#08lx" , __entry->hva) +TP_printk ("mmu notifier set pte hva: %#016lx" , __entry->hva) ); TRACE_EVENT(kvm_age_hva,
@@ -182,7 +182,7 @@ TRACE_EVENT(kvm_age_hva, __entry->end = end; ), -TP_printk ("mmu notifier age hva: %#08lx -- %#08lx" , +TP_printk ("mmu notifier age hva: %#016lx -- %#016lx" , __entry->start, __entry->end) );
@@ -198,7 +198,7 @@ TRACE_EVENT(kvm_test_age_hva, __entry->hva = hva; ), -TP_printk ("mmu notifier test age hva: %#08lx" , __entry->hva) +TP_printk ("mmu notifier test age hva: %#016lx" , __entry->hva) ); TRACE_EVENT(kvm_set_way_flush,
arch/arm64/kvm/trace_handle_exit.h +3 -3
@@ -22,7 +22,7 @@ TRACE_EVENT(kvm_wfx_arm64, __entry->is_wfe = is_wfe; ), -TP_printk ("guest executed wf%c at: 0x%08lx" , +TP_printk ("guest executed wf%c at: 0x%016lx" , __entry->is_wfe ?'e' :'i' , __entry->vcpu_pc) );
@@ -42,7 +42,7 @@ TRACE_EVENT(kvm_hvc_arm64, __entry->imm = imm; ), -TP_printk ("HVC at 0x%08lx (r0: 0x%08lx, imm: 0x%lx)" , +TP_printk ("HVC at 0x%016lx (r0: 0x%016lx, imm: 0x%lx)" , __entry->vcpu_pc, __entry->r0, __entry->imm) );
@@ -135,7 +135,7 @@ TRACE_EVENT(trap_reg, __entry->write_value = write_value; ), -TP_printk ("%s %s reg %d (0x%08llx)" , __entry->fn, __entry->is_write?"write to" :"read from" , __entry->reg, __entry->write_value) +TP_printk ("%s %s reg %d (0x%016llx)" , __entry->fn, __entry->is_write?"write to" :"read from" , __entry->reg, __entry->write_value) ); TRACE_EVENT(kvm_handle_sys_reg,
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerPATCH 9/9 KVM: arm64: Update page shift if stage 2 block mapping not supported
In reply to Marc ZyngierFrom: Alexandru Elisei <[email protected]>
Commit 196f878a7ac2e (" KVM: arm/arm64: Signal SIGBUS when stage2 discovers hwpoison memory") modifies user_mem_abort() to send a SIGBUS signal when the fault IPA maps to a hwpoisoned page. Commit 1559b7583ff6 ("KVM:
arm/arm64: Re-check VMA on detecting a poisoned page") changed kvm_send_hwpoison_signal() to use the page shift instead of the VMA because at that point the code had already released the mmap lock, which means userspace could have modified the VMA.
If userspace uses hugetlbfs for the VM memory, user_mem_abort() tries to map the guest fault IPA using block mappings in stage 2. That is not always possible, if, for example, userspace uses dirty page logging for the VM. Update the page shift appropriately in those cases when we downgrade the stage 2 entry from a block mapping to a page.
--- arch/arm64/kvm/mmu.c | 1 + 1 file changed, 1 insertion(+)
arch/arm64/kvm/mmu.c +1 -0
@@ -1871,6 +1871,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, !fault_supports_stage2_huge_mapping(memslot, hva, vma_pagesize)) { force_pte = true; vma_pagesize =PAGE_SIZE ; + vma_shift =PAGE_SHIFT ; }/*
Signature · 6 lines
2.27.0 _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Paolo Bonzini
maintainerQuoted 5 lines · Marc Zyngier
Hi Paolo,
Here's a bunch of fixes for 5.9. The gist of it is the stolen time rework from Andrew, but we also have a couple of MM fixes that have surfaced as people have started to use hugetlbfs in anger.
Hi Marc,
I'll get to this next Friday.
Paolo
Quoted 41 lines
Please pull,
M.The following changes since commit
9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.gittags/kvmarm-fixes-5.9-1for you to fetch changes up to
7b75cd5128421c673153efb1236705696a1a9812:KVM: arm64: Update page shift if stage 2 block mapping not supported (2020-09-04 10:53:48 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for Linux 5.9, take #1- Multiple stolen time fixes, with a new capability to match x86
- Fix for hugetlbfs mappings when PUD and PMD are the same level
- Fix for hugetlbfs mappings when PTE mappings are enforced (dirty logging, for example)
- Fix tracing output of 64bit values----------------------------------------------------------------
Alexandru Elisei (1):
KVM: arm64: Update page shift if stage 2 block mapping not supportedAndrew Jones (6):
KVM: arm64: pvtime: steal-time is only supported when configured
KVM: arm64: pvtime: Fix potential loss of stolen time
KVM: arm64: Drop type input fromkvm_put_guest
KVM: arm64: pvtime: Fix stolen time accounting across migration
KVM: Documentation: Minor fixups
arm64/x86: KVM: Introduce steal-time capMarc Zyngier (2):
KVM: arm64: Do not try to map PUDs when they are folded into PMD
KVM: arm64: Fix address truncation in traces
Quoted 12 lines
Documentation/virt/kvm/api.rst | 22 ++++++++++++++++++---- arch/arm64/include/asm/kvm_host.h | 2 +- arch/arm64/kvm/arm.c | 3 +++ arch/arm64/kvm/mmu.c | 8 +++++++- arch/arm64/kvm/pvtime.c | 29 +++++++++++++---------------- arch/arm64/kvm/trace_arm.h | 16 ++++++++-------- arch/arm64/kvm/trace_handle_exit.h | 6 +++--- arch/x86/kvm/x86.c | 3 +++ include/linux/kvm_host.h | 31 ++++++++++++++++++++++++++----- include/uapi/linux/kvm.h | 1 + 10 files changed, 83 insertions(+), 38 deletions(-)
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Marc Zyngier
maintainerQuoted 10 lines · Paolo Bonzini
Quoted 5 lines · Marc Zyngier
Hi Paolo,
Here's a bunch of fixes for 5.9. The gist of it is the stolen time rework from Andrew, but we also have a couple of MM fixes that have surfaced as people have started to use hugetlbfs in anger.
Hi Marc,
I'll get to this next Friday.
Thanks. I may have another one for you by then though...
M.
Signature · 5 lines
Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Paolo Bonzini
maintainerQuoted 8 lines · Marc Zyngier
Quoted 7 lines · Paolo Bonzini
Quoted 5 lines · Marc Zyngier
Hi Paolo,
Here's a bunch of fixes for 5.9. The gist of it is the stolen time rework from Andrew, but we also have a couple of MM fixes that have surfaced as people have started to use hugetlbfs in anger.
Quoted 5 lines
Quoted 3 lines
Hi Marc,
I'll get to this next Friday.
Thanks. I may have another one for you by then though...
Sure, you can choose whether to send a separate tag or update this one.
Paolo
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm