selftests: KVM: Align SMCCC call with the spec in steal_time

Signed-off-by Sasha Levin <[email protected]>

---
 tools/testing/selftests/kvm/steal_time.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

tools/testing/selftests/kvm/steal_time.c +2 -2

index fcc840088c91..7daedee3e7ee 100644
@@ -120,12 +120,12 @@ struct st_time {
 	uint64_t st_time;
 };
 
-static int64_t smccc(uint32_t func, uint32_t arg)
+static int64_t smccc(uint32_t func, uint64_t arg)
 {
 	unsigned long ret;
 
 	asm volatile(
-		"mov	x0, %1\n"
+		"mov	w0, %w1\n"
 		"mov	x1, %2\n"
 		"hvc	#0\n"
 		"mov	%0, x0\n"

Signature · 1 line

2.33.0

Sasha Levin

author maintainer

2021-10-06 11:12 UTC #1 lore raw

PATCH 2/7 KVM: x86: Handle SRCU initialization failure during page track init

From: Haimin Zhang <[email protected]>

[ Upstream commit eb7511bf9182292ef1df1082d23039e856d1ddfb ]

Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller.

Reported-by TCS Robot <[email protected]>

Signed-off-by Haimin Zhang <[email protected]>

Message-Id: <[email protected]>

[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/include/asm/kvm_page_track.h | 2 +-
 arch/x86/kvm/mmu/page_track.c         | 4 ++--
 arch/x86/kvm/x86.c                    | 7 ++++++-
 3 files changed, 9 insertions(+), 4 deletions(-)

arch/x86/include/asm/kvm_page_track.h +1 -1

index 87bd6025d91d..6a5f3acf2b33 100644
@@ -46,7 +46,7 @@ struct kvm_page_track_notifier_node {
 			    struct kvm_page_track_notifier_node *node);
 };
 
-void kvm_page_track_init(struct kvm *kvm);
+int kvm_page_track_init(struct kvm *kvm);
 void kvm_page_track_cleanup(struct kvm *kvm);
 
 void kvm_page_track_free_memslot(struct kvm_memory_slot *slot);

arch/x86/kvm/mmu/page_track.c +2 -2

index 8443a675715b..81cf4babbd0b 100644
@@ -163,13 +163,13 @@ void kvm_page_track_cleanup(struct kvm *kvm)
 	cleanup_srcu_struct(&head->track_srcu);
 }
 
-void kvm_page_track_init(struct kvm *kvm)
+int kvm_page_track_init(struct kvm *kvm)
 {
 	struct kvm_page_track_notifier_head *head;
 
 	head = &kvm->arch.track_notifier_head;
-	init_srcu_struct(&head->track_srcu);
 	INIT_HLIST_HEAD(&head->track_notifier_list);
+	return init_srcu_struct(&head->track_srcu);
 }
 
 /*

arch/x86/kvm/x86.c +6 -1

index 75c59ad27e9f..d65da3b5837b 100644
@@ -10392,9 +10392,15 @@ void kvm_arch_free_vm(struct kvm *kvm)
 
 int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 {
+	int ret;
+
 	if (type)
 		return -EINVAL;
 
+	ret = kvm_page_track_init(kvm);
+	if (ret)
+		return ret;
+
 	INIT_HLIST_HEAD(&kvm->arch.mask_notifier_list);
 	INIT_LIST_HEAD(&kvm->arch.active_mmu_pages);
 	INIT_LIST_HEAD(&kvm->arch.zapped_obsolete_pages);

@@ -10421,7 +10427,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 	INIT_DELAYED_WORK(&kvm->arch.kvmclock_sync_work, kvmclock_sync_fn);
 
 	kvm_hv_init_vm(kvm);
-	kvm_page_track_init(kvm);
 	kvm_mmu_init_vm(kvm);
 
 	return kvm_x86_ops.vm_init(kvm);

Signature · 1 line

2.33.0

Paolo Bonzini

maintainer Acked-by on v1 2/7

2021-10-06 11:23 UTC #2 lore raw

Re: [PATCH MANUALSEL 5.10 2/7] KVM: x86: Handle SRCU initialization failure during page track init

Quoted 75 lines · Sasha Levin

From: Haimin Zhang <[email protected]>

[ Upstream commit eb7511bf9182292ef1df1082d23039e856d1ddfb ]

Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller.

Reported-by TCS Robot <[email protected]>

Signed-off-by Haimin Zhang <[email protected]>

Message-Id: <[email protected]>

[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]

Signed-off-by Sasha Levin <[email protected]>

---
  arch/x86/include/asm/kvm_page_track.h | 2 +-
  arch/x86/kvm/mmu/page_track.c         | 4 ++--
  arch/x86/kvm/x86.c                    | 7 ++++++-
  3 files changed, 9 insertions(+), 4 deletions(-)

arch/x86/include/asm/kvm_page_track.h +1 -1

index 87bd6025d91d..6a5f3acf2b33 100644
@@ -46,7 +46,7 @@ struct kvm_page_track_notifier_node {
  			    struct kvm_page_track_notifier_node *node);
  };
 
-void kvm_page_track_init(struct kvm *kvm);
+int kvm_page_track_init(struct kvm *kvm);
  void kvm_page_track_cleanup(struct kvm *kvm);
 
  void kvm_page_track_free_memslot(struct kvm_memory_slot *slot);

arch/x86/kvm/mmu/page_track.c +2 -2

index 8443a675715b..81cf4babbd0b 100644
@@ -163,13 +163,13 @@ void kvm_page_track_cleanup(struct kvm *kvm)
  	cleanup_srcu_struct(&head->track_srcu);
  }
 
-void kvm_page_track_init(struct kvm *kvm)
+int kvm_page_track_init(struct kvm *kvm)
  {
  	struct kvm_page_track_notifier_head *head;
 
  	head = &kvm->arch.track_notifier_head;
-	init_srcu_struct(&head->track_srcu);
  	INIT_HLIST_HEAD(&head->track_notifier_list);
+	return init_srcu_struct(&head->track_srcu);
  }
 
  /*

arch/x86/kvm/x86.c +6 -0

index 75c59ad27e9f..d65da3b5837b 100644
@@ -10392,9 +10392,15 @@ void kvm_arch_free_vm(struct kvm *kvm)
 
  int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
  {
+	int ret;
+
  	if (type)
  		return -EINVAL;
 
+	ret = kvm_page_track_init(kvm);
+	if (ret)
+		return ret;
+
  	INIT_HLIST_HEAD(&kvm->arch.mask_notifier_list);
  	INIT_LIST_HEAD(&kvm->arch.active_mmu_pages);
  	INIT_LIST_HEAD(&kvm->arch.zapped_obsolete_pages);

arch/x86/kvm/x86.c int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) · line 10432

Quoted 7 lines

arch/x86/kvm/x86.c +0 -1

@@ -10421,7 +10427,6 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
  	INIT_DELAYED_WORK(&kvm->arch.kvmclock_sync_work, kvmclock_sync_fn);
 
  	kvm_hv_init_vm(kvm);
-	kvm_page_track_init(kvm);
  	kvm_mmu_init_vm(kvm);
 
  	return kvm_x86_ops.vm_init(kvm);

Sasha Levin

author maintainer

2021-10-06 11:12 UTC #3 lore raw

PATCH 3/7 KVM: do not shrink halt_poll_ns below grow_start

From: Sergey Senozhatsky <[email protected]>

[ Upstream commit ae232ea460888dc5a8b37e840c553b02521fbf18 ]

grow_halt_poll_ns() ignores values between 0 and halt_poll_ns_grow_start (10000 by default). However, when we shrink halt_poll_ns we may fall way below halt_poll_ns_grow_start and endup with halt_poll_ns values that don't make a lot of sense: like 1 or 9, or 19.

VCPU1 trace (halt_poll_ns_shrink equals 2):

VCPU1 grow 10000
VCPU1 shrink 5000
VCPU1 shrink 2500
VCPU1 shrink 1250
VCPU1 shrink 625
VCPU1 shrink 312
VCPU1 shrink 156
VCPU1 shrink 78
VCPU1 shrink 39
VCPU1 shrink 19
VCPU1 shrink 9
VCPU1 shrink 4

Mirror what grow_halt_poll_ns() does and set halt_poll_ns to 0 as soon as new shrink-ed halt_poll_ns value falls below halt_poll_ns_grow_start.

Signed-off-by Sergey Senozhatsky <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 virt/kvm/kvm_main.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

virt/kvm/kvm_main.c +5 -1

index 0e4310c415a8..57c0c3b18bde 100644
@@ -2756,15 +2756,19 @@ static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
 
 static void shrink_halt_poll_ns(struct kvm_vcpu *vcpu)
 {
-	unsigned int old, val, shrink;
+	unsigned int old, val, shrink, grow_start;
 
 	old = val = vcpu->halt_poll_ns;
 	shrink = READ_ONCE(halt_poll_ns_shrink);
+	grow_start = READ_ONCE(halt_poll_ns_grow_start);
 	if (shrink == 0)
 		val = 0;
 	else
 		val /= shrink;
 
+	if (val < grow_start)
+		val = 0;
+
 	vcpu->halt_poll_ns = val;
 	trace_kvm_halt_poll_ns_shrink(vcpu->vcpu_id, val, old);
 }

Signature · 1 line

2.33.0

Paolo Bonzini

maintainer Acked-by on v1 3/7

2021-10-06 11:23 UTC #4 lore raw

Re: [PATCH MANUALSEL 5.10 3/7] KVM: do not shrink halt_poll_ns below grow_start

Quoted 55 lines · Sasha Levin

From: Sergey Senozhatsky <[email protected]>
[ Upstream commit ae232ea460888dc5a8b37e840c553b02521fbf18 ]
grow_halt_poll_ns() ignores values between 0 and halt_poll_ns_grow_start (10000 by default). However, when we shrink halt_poll_ns we may fall way below halt_poll_ns_grow_start and endup with halt_poll_ns values that don't make a lot of sense: like 1 or 9, or 19.
VCPU1 trace (halt_poll_ns_shrink equals 2):
VCPU1 grow 10000
VCPU1 shrink 5000
VCPU1 shrink 2500
VCPU1 shrink 1250
VCPU1 shrink 625
VCPU1 shrink 312
VCPU1 shrink 156
VCPU1 shrink 78
VCPU1 shrink 39
VCPU1 shrink 19
VCPU1 shrink 9
VCPU1 shrink 4
Mirror what grow_halt_poll_ns() does and set halt_poll_ns to 0 as soon as new shrink-ed halt_poll_ns value falls below halt_poll_ns_grow_start.
Signed-off-by Sergey Senozhatsky <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
Message-Id: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
  virt/kvm/kvm_main.c | 6 +++++-
  1 file changed, 5 insertions(+), 1 deletion(-)
virt/kvm/kvm_main.c +2 -1
index 0e4310c415a8..57c0c3b18bde 100644
@@ -2756,15 +2756,19 @@ static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
 
  static void shrink_halt_poll_ns(struct kvm_vcpu *vcpu)
  {
-	unsigned int old, val, shrink;
+	unsigned int old, val, shrink, grow_start;
 
  	old = val = vcpu->halt_poll_ns;
  	shrink = READ_ONCE(halt_poll_ns_shrink);
+	grow_start = READ_ONCE(halt_poll_ns_grow_start);
  	if (shrink == 0)

virt/kvm/kvm_main.c static void grow_halt_poll_ns(struct kvm_vcpu *vcpu) · line 2774

Quoted 10 lines

virt/kvm/kvm_main.c +3 -0

  		val = 0;
  	else
  		val /= shrink;
 
+	if (val < grow_start)
+		val = 0;
+
  	vcpu->halt_poll_ns = val;
  	trace_kvm_halt_poll_ns_shrink(vcpu->vcpu_id, val, old);
  }

Sasha Levin

author maintainer

2021-10-06 11:12 UTC #5 lore raw

PATCH 4/7 KVM: x86: VMX: synthesize invalid VM exit when emulating invalid guest state

From: Maxim Levitsky <[email protected]>

[ Upstream commit c42dec148b3e1a88835e275b675e5155f99abd43 ]

Since no actual VM entry happened, the VM exit information is stale. To avoid this, synthesize an invalid VM guest state VM exit.

Signed-off-by Maxim Levitsky <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/kvm/vmx/vmx.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

arch/x86/kvm/vmx/vmx.c +14 -3

index fcd8bcb7e0ea..e3af56f05a37 100644
@@ -6670,10 +6670,21 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
 		     vmx->loaded_vmcs->soft_vnmi_blocked))
 		vmx->loaded_vmcs->entry_time = ktime_get();
 
-	/* Don't enter VMX if guest state is invalid, let the exit handler
-	   start emulation until we arrive back to a valid state */
-	if (vmx->emulation_required)
+	/*
+	 * Don't enter VMX if guest state is invalid, let the exit handler
+	 * start emulation until we arrive back to a valid state.  Synthesize a
+	 * consistency check VM-Exit due to invalid guest state and bail.
+	 */
+	if (unlikely(vmx->emulation_required)) {
+		vmx->fail = 0;
+		vmx->exit_reason.full = EXIT_REASON_INVALID_STATE;
+		vmx->exit_reason.failed_vmentry = 1;
+		kvm_register_mark_available(vcpu, VCPU_EXREG_EXIT_INFO_1);
+		vmx->exit_qualification = ENTRY_FAIL_DEFAULT;
+		kvm_register_mark_available(vcpu, VCPU_EXREG_EXIT_INFO_2);
+		vmx->exit_intr_info = 0;
 		return EXIT_FASTPATH_NONE;
+	}
 
 	if (vmx->ple_window_dirty) {
 		vmx->ple_window_dirty = false;

Signature · 1 line

2.33.0

Paolo Bonzini

maintainer

2021-10-06 11:22 UTC #6 lore raw

Re: [PATCH MANUALSEL 5.10 4/7] KVM: x86: VMX: synthesize invalid VM exit when emulating invalid guest state

Quoted 36 lines · Sasha Levin

From: Maxim Levitsky <[email protected]>
[ Upstream commit c42dec148b3e1a88835e275b675e5155f99abd43 ]
Since no actual VM entry happened, the VM exit information is stale. To avoid this, synthesize an invalid VM guest state VM exit.
Suggested-by Sean Christopherson <[email protected]>
Signed-off-by Maxim Levitsky <[email protected]>
Message-Id: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
  arch/x86/kvm/vmx/vmx.c | 17 ++++++++++++++---
  1 file changed, 14 insertions(+), 3 deletions(-)
arch/x86/kvm/vmx/vmx.c +8 -3
index fcd8bcb7e0ea..e3af56f05a37 100644
@@ -6670,10 +6670,21 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
  		     vmx->loaded_vmcs->soft_vnmi_blocked))
  		vmx->loaded_vmcs->entry_time = ktime_get();
 
-	/* Don't enter VMX if guest state is invalid, let the exit handler
-	   start emulation until we arrive back to a valid state */
-	if (vmx->emulation_required)
+	/*
+	 * Don't enter VMX if guest state is invalid, let the exit handler
+	 * start emulation until we arrive back to a valid state.  Synthesize a
+	 * consistency check VM-Exit due to invalid guest state and bail.
+	 */
+	if (unlikely(vmx->emulation_required)) {
+		vmx->fail = 0;
+		vmx->exit_reason.full = EXIT_REASON_INVALID_STATE;

arch/x86/kvm/vmx/vmx.c static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu) · line 6690

Quoted 10 lines

arch/x86/kvm/vmx/vmx.c +6 -0

+		vmx->exit_reason.failed_vmentry = 1;
+		kvm_register_mark_available(vcpu, VCPU_EXREG_EXIT_INFO_1);
+		vmx->exit_qualification = ENTRY_FAIL_DEFAULT;
+		kvm_register_mark_available(vcpu, VCPU_EXREG_EXIT_INFO_2);
+		vmx->exit_intr_info = 0;
  		return EXIT_FASTPATH_NONE;
+	}
 
  	if (vmx->ple_window_dirty) {
  		vmx->ple_window_dirty = false;

NACK for this one.

The others are good, I'll ack them individually though. Thanks for setting this up!

Paolo

Sasha Levin

author maintainer

2021-10-06 11:12 UTC #7 lore raw

PATCH 5/7 kvm: x86: Add AMD PMU MSRs to msrs_to_save_all[]

From: Fares Mehanna <[email protected]>

[ Upstream commit e1fc1553cd78292ab3521c94c9dd6e3e70e606a1 ]

Intel PMU MSRs is in msrs_to_save_all[], so add AMD PMU MSRs to have a consistent behavior between Intel and AMD when using KVM_GET_MSRS, KVM_SET_MSRS or KVM_GET_MSR_INDEX_LIST.

We have to add legacy and new MSRs to handle guests running without X86_FEATURE_PERFCTR_CORE.

Signed-off-by Fares Mehanna <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/kvm/x86.c | 7 +++++++
 1 file changed, 7 insertions(+)

arch/x86/kvm/x86.c +7 -0

index d65da3b5837b..b885063dc393 100644
@@ -1250,6 +1250,13 @@ static const u32 msrs_to_save_all[] = {
 	MSR_ARCH_PERFMON_EVENTSEL0 + 12, MSR_ARCH_PERFMON_EVENTSEL0 + 13,
 	MSR_ARCH_PERFMON_EVENTSEL0 + 14, MSR_ARCH_PERFMON_EVENTSEL0 + 15,
 	MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,
+
+	MSR_K7_EVNTSEL0, MSR_K7_EVNTSEL1, MSR_K7_EVNTSEL2, MSR_K7_EVNTSEL3,
+	MSR_K7_PERFCTR0, MSR_K7_PERFCTR1, MSR_K7_PERFCTR2, MSR_K7_PERFCTR3,
+	MSR_F15H_PERF_CTL0, MSR_F15H_PERF_CTL1, MSR_F15H_PERF_CTL2,
+	MSR_F15H_PERF_CTL3, MSR_F15H_PERF_CTL4, MSR_F15H_PERF_CTL5,
+	MSR_F15H_PERF_CTR0, MSR_F15H_PERF_CTR1, MSR_F15H_PERF_CTR2,
+	MSR_F15H_PERF_CTR3, MSR_F15H_PERF_CTR4, MSR_F15H_PERF_CTR5,
 };
 
 static u32 msrs_to_save[ARRAY_SIZE(msrs_to_save_all)];

Signature · 1 line

2.33.0

Paolo Bonzini

maintainer Acked-by on v1 5/7

2021-10-06 11:23 UTC #8 lore raw

Re: [PATCH MANUALSEL 5.10 5/7] kvm: x86: Add AMD PMU MSRs to msrs_to_save_all[]

Quoted 28 lines · Sasha Levin

From: Fares Mehanna <[email protected]>
[ Upstream commit e1fc1553cd78292ab3521c94c9dd6e3e70e606a1 ]
Intel PMU MSRs is in msrs_to_save_all[], so add AMD PMU MSRs to have a consistent behavior between Intel and AMD when using KVM_GET_MSRS, KVM_SET_MSRS or KVM_GET_MSR_INDEX_LIST.
We have to add legacy and new MSRs to handle guests running without X86_FEATURE_PERFCTR_CORE.
Signed-off-by Fares Mehanna <[email protected]>
Message-Id: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
  arch/x86/kvm/x86.c | 7 +++++++
  1 file changed, 7 insertions(+)
arch/x86/kvm/x86.c +0 -0
index d65da3b5837b..b885063dc393 100644
@@ -1250,6 +1250,13 @@ static const u32 msrs_to_save_all[] = {
  	MSR_ARCH_PERFMON_EVENTSEL0 + 12, MSR_ARCH_PERFMON_EVENTSEL0 + 13,
  	MSR_ARCH_PERFMON_EVENTSEL0 + 14, MSR_ARCH_PERFMON_EVENTSEL0 + 15,
  	MSR_ARCH_PERFMON_EVENTSEL0 + 16, MSR_ARCH_PERFMON_EVENTSEL0 + 17,

arch/x86/kvm/x86.c static const u32 msrs_to_save_all[] = { · line 1262

Quoted 10 lines

arch/x86/kvm/x86.c +7 -0

+
+	MSR_K7_EVNTSEL0, MSR_K7_EVNTSEL1, MSR_K7_EVNTSEL2, MSR_K7_EVNTSEL3,
+	MSR_K7_PERFCTR0, MSR_K7_PERFCTR1, MSR_K7_PERFCTR2, MSR_K7_PERFCTR3,
+	MSR_F15H_PERF_CTL0, MSR_F15H_PERF_CTL1, MSR_F15H_PERF_CTL2,
+	MSR_F15H_PERF_CTL3, MSR_F15H_PERF_CTL4, MSR_F15H_PERF_CTL5,
+	MSR_F15H_PERF_CTR0, MSR_F15H_PERF_CTR1, MSR_F15H_PERF_CTR2,
+	MSR_F15H_PERF_CTR3, MSR_F15H_PERF_CTR4, MSR_F15H_PERF_CTR5,
  };
 
  static u32 msrs_to_save[ARRAY_SIZE(msrs_to_save_all)];

Sasha Levin

author maintainer

2021-10-06 11:13 UTC #9 lore raw

PATCH 6/7 KVM: x86: nSVM: restore int_vector in svm_clear_vintr

From: Maxim Levitsky <[email protected]>

[ Upstream commit aee77e1169c1900fe4248dc186962e745b479d9e ]

In svm_clear_vintr we try to restore the virtual interrupt injection that might be pending, but we fail to restore the interrupt vector.

Signed-off-by Maxim Levitsky <[email protected]>

Message-Id: <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/kvm/svm/svm.c | 2 ++
 1 file changed, 2 insertions(+)

arch/x86/kvm/svm/svm.c +2 -0

index 1c23aee3778c..5e1d7396a6b8 100644
@@ -1497,6 +1497,8 @@ static void svm_clear_vintr(struct vcpu_svm *svm)
 			(svm->nested.ctl.int_ctl & V_TPR_MASK));
 		svm->vmcb->control.int_ctl |= svm->nested.ctl.int_ctl &
 			V_IRQ_INJECTION_BITS_MASK;
+
+		svm->vmcb->control.int_vector = svm->nested.ctl.int_vector;
 	}
 
 	vmcb_mark_dirty(svm->vmcb, VMCB_INTR);

Signature · 1 line

2.33.0

Paolo Bonzini

maintainer Acked-by on v1 6/7

2021-10-06 11:25 UTC #10 lore raw

Re: [PATCH MANUALSEL 5.10 6/7] KVM: x86: nSVM: restore int_vector in svm_clear_vintr

Quoted 22 lines · Sasha Levin

From: Maxim Levitsky <[email protected]>
[ Upstream commit aee77e1169c1900fe4248dc186962e745b479d9e ]
In svm_clear_vintr we try to restore the virtual interrupt injection that might be pending, but we fail to restore the interrupt vector.
Signed-off-by Maxim Levitsky <[email protected]>
Message-Id: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
  arch/x86/kvm/svm/svm.c | 2 ++
  1 file changed, 2 insertions(+)
arch/x86/kvm/svm/svm.c +0 -0
index 1c23aee3778c..5e1d7396a6b8 100644

arch/x86/kvm/svm/svm.c static void svm_clear_vintr(struct vcpu_svm *svm) · line 1504

Quoted 8 lines

arch/x86/kvm/svm/svm.c +2 -0

@@ -1497,6 +1497,8 @@ static void svm_clear_vintr(struct vcpu_svm *svm)
  			(svm->nested.ctl.int_ctl & V_TPR_MASK));
  		svm->vmcb->control.int_ctl |= svm->nested.ctl.int_ctl &
  			V_IRQ_INJECTION_BITS_MASK;
+
+		svm->vmcb->control.int_vector = svm->nested.ctl.int_vector;
  	}
 
  	vmcb_mark_dirty(svm->vmcb, VMCB_INTR);

Sasha Levin

author maintainer

2021-10-06 11:13 UTC #11 lore raw

PATCH 7/7 ALSA: pcsp: Make hrtimer forwarding more robust

From: Thomas Gleixner <[email protected]>

[ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ]

The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument.

pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case.

Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces.

Signed-off-by Thomas Gleixner <[email protected]>

Cc [email protected]

Cc Takashi Iwai <[email protected]>

Cc Jaroslav Kysela <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 sound/drivers/pcsp/pcsp_lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

sound/drivers/pcsp/pcsp_lib.c +1 -1

index ed40d0f7432c..773db4bf0876 100644
@@ -143,7 +143,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle)
 	if (pointer_update)
 		pcsp_pointer_update(chip);
 
-	hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns));
+	hrtimer_forward_now(handle, ns_to_ktime(ns));
 
 	return HRTIMER_RESTART;
 }

Signature · 1 line

2.33.0

Paolo Bonzini

maintainer Acked-by on v1 1/7

2021-10-06 11:22 UTC #12 lore raw

Quoted 32 lines · Sasha Levin

From: Oliver Upton <[email protected]>
[ Upstream commit 01f91acb55be7aac3950b89c458bcea9ef6e4f49 ]
The SMC64 calling convention passes a function identifier in w0 and its parameters in x1-x17. Given this, there are two deviations in the SMC64 call performed by the steal_time test: the function identifier is assigned to a 64 bit register and the parameter is only 32 bits wide.
Align the call with the SMCCC by using a 32 bit register to handle the function identifier and increasing the parameter width to 64 bits.
Suggested-by Andrew Jones <[email protected]>
Signed-off-by Oliver Upton <[email protected]>
Reviewed-by Andrew Jones <[email protected]>
Message-Id: <[email protected]>
Signed-off-by Paolo Bonzini <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
---
  tools/testing/selftests/kvm/steal_time.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
tools/testing/selftests/kvm/steal_time.c +0 -1
index fcc840088c91..7daedee3e7ee 100644
@@ -120,12 +120,12 @@ struct st_time {
  	uint64_t st_time;
  };
 
-static int64_t smccc(uint32_t func, uint32_t arg)

tools/testing/selftests/kvm/steal_time.c struct st_time { · line 131

Quoted 10 lines

tools/testing/selftests/kvm/steal_time.c +2 -1

+static int64_t smccc(uint32_t func, uint64_t arg)
  {
  	unsigned long ret;
 
  	asm volatile(
-		"mov	x0, %1\n"
+		"mov	w0, %w1\n"
  		"mov	x1, %2\n"
  		"hvc	#0\n"
  		"mov	%0, x0\n"

Just fixing tests, but anyway: