linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling
@ 2022-04-14  5:11 Suravee Suthikulpanit
  2022-04-14  5:11 ` [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast() Suravee Suthikulpanit
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Suravee Suthikulpanit @ 2022-04-14  5:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: pbonzini, mlevitsk, seanjc, joro, jon.grimm, wei.huang2,
	terry.bowman, Suravee Suthikulpanit

This series introduce a fast-path when handling AVIC incomplete IPI #vmexit
for AVIC and x2AVIC, and introduce a new tracepoint for the slow-path
processing.

Please note that the prereq of this series is:
  [PATCH v2 00/12] Introducing AMD x2APIC Virtualization (x2AVIC) support
  (https://lore.kernel.org/lkml/20220412115822.14351-2-suravee.suthikulpanit@amd.com/T/)

Regards,
Suravee

Suravee Suthikulpanit (2):
  KVM: SVM: Introduce avic_kick_target_vcpus_fast()
  KVM: SVM: Introduce trace point for the slow-path of
    avic_kic_target_vcpus

 arch/x86/kvm/svm/avic.c | 93 +++++++++++++++++++++++++++++++++++++++--
 arch/x86/kvm/trace.h    | 20 +++++++++
 arch/x86/kvm/x86.c      |  1 +
 3 files changed, 110 insertions(+), 4 deletions(-)

-- 
2.25.1


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast()
  2022-04-14  5:11 [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit
@ 2022-04-14  5:11 ` Suravee Suthikulpanit
  2022-04-14 19:21   ` Sean Christopherson
  2022-04-18 11:02   ` Maxim Levitsky
  2022-04-14  5:11 ` [PATCH 2/2] KVM: SVM: Introduce trace point for the slow-path of avic_kic_target_vcpus Suravee Suthikulpanit
  2022-04-18 14:39 ` [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit
  2 siblings, 2 replies; 7+ messages in thread
From: Suravee Suthikulpanit @ 2022-04-14  5:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: pbonzini, mlevitsk, seanjc, joro, jon.grimm, wei.huang2,
	terry.bowman, Suravee Suthikulpanit

Currently, an AVIC-enabled VM suffers from performance bottleneck
when scaling to large number of vCPUs for I/O intensive workloads.

In such case, a vCPU often executes halt instruction to get into idle state
waiting for interrupts, in which KVM would de-schedule the vCPU from
physical CPU.

When AVIC HW tries to deliver interrupt to the halting vCPU, it would
result in AVIC incomplete IPI #vmexit to notify KVM to reschedule
the target vCPU into running state.

Investigation has shown the main hotspot is in the kvm_apic_match_dest()
in the following call stack where it tries to find target vCPUs
corresponded to the information in the ICRH/ICRL registers.

  - handle_exit
    - svm_invoke_exit_handler
      - avic_incomplete_ipi_interception
        - kvm_apic_match_dest

However, AVIC provides hints in the #vmexit info, which can be used to
retrieve the destination guest physical APIC ID.

In addition, since QEMU defines guest physical APIC ID to be the same as
vCPU ID, it can be used to quickly identify the target vCPU to deliver IPI,
and avoid the overhead from searching through all vCPUs to match the target
vCPU.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/x86/kvm/svm/avic.c | 91 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 87 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index abcf761c0c53..92d8e0de1fb4 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -351,11 +351,94 @@ void avic_ring_doorbell(struct kvm_vcpu *vcpu)
 	put_cpu();
 }
 
-static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
-				   u32 icrl, u32 icrh)
+/*
+ * A fast-path version of avic_kick_target_vcpus(), which attempts to match
+ * destination APIC ID to vCPU without looping through all vCPUs.
+ */
+static int avic_kick_target_vcpus_fast(struct kvm *kvm, struct kvm_lapic *source,
+				       u32 icrl, u32 icrh, u32 index)
 {
+	u32 dest, apic_id;
 	struct kvm_vcpu *vcpu;
+	int dest_mode = icrl & APIC_DEST_MASK;
+	int shorthand = icrl & APIC_SHORT_MASK;
+	struct kvm_svm *kvm_svm = to_kvm_svm(kvm);
+	u32 *avic_logical_id_table = page_address(kvm_svm->avic_logical_id_table_page);
+
+	if (shorthand != APIC_DEST_NOSHORT)
+		return -EINVAL;
+
+	/*
+	 * The AVIC incomplete IPI #vmexit info provides index into
+	 * the physical APIC ID table, which can be used to derive 
+	 * guest physical APIC ID.
+	 */
+	if (dest_mode == APIC_DEST_PHYSICAL) {
+		apic_id = index;
+	} else {
+		if (!apic_x2apic_mode(source)) {
+			/* For xAPIC logical mode, the index is for logical APIC table. */
+			apic_id = avic_logical_id_table[index] & 0x1ff;
+		} else {
+			/* For x2APIC logical mode, cannot leverage the index.
+			 * Instead, calculate physical ID from logical ID in ICRH.
+			 */
+			int apic;
+			int first = ffs(icrh & 0xffff);
+			int last = fls(icrh & 0xffff);
+			int cluster = (icrh & 0xffff0000) >> 16;
+
+			/*
+			 * If the x2APIC logical ID sub-field (i.e. icrh[15:0]) contains zero
+			 * or more than 1 bits, we cannot match just one vcpu to kick for
+			 * fast path.
+			 */
+			if (!first || (first != last))
+				return -EINVAL;
+
+			apic = first - 1;
+			if ((apic < 0) || (apic > 15) || (cluster >= 0xfffff))
+				return -EINVAL;
+			apic_id = (cluster << 4) + apic;
+		}
+	}
+
+	/*
+	 * Assuming vcpu ID is the same as physical apic ID,
+	 * and use it to retrieve the target vCPU.
+	 */
+	vcpu = kvm_get_vcpu_by_id(kvm, apic_id);
+	if (!vcpu)
+		return -EINVAL;
+
+	if (apic_x2apic_mode(vcpu->arch.apic))
+		dest = icrh;
+	else
+		dest = GET_XAPIC_DEST_FIELD(icrh);
+
+	/*
+	 * Try matching the destination APIC ID with the vCPU.
+	 */
+	if (kvm_apic_match_dest(vcpu, source, shorthand, dest, dest_mode)) {
+		vcpu->arch.apic->irr_pending = true;
+		svm_complete_interrupt_delivery(vcpu,
+						icrl & APIC_MODE_MASK,
+						icrl & APIC_INT_LEVELTRIG,
+						icrl & APIC_VECTOR_MASK);
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
+static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
+				   u32 icrl, u32 icrh, u32 index)
+{
 	unsigned long i;
+	struct kvm_vcpu *vcpu;
+
+	if (!avic_kick_target_vcpus_fast(kvm, source, icrl, icrh, index))
+		return;
 
 	/*
 	 * Wake any target vCPUs that are blocking, i.e. waiting for a wake
@@ -388,7 +471,7 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu *vcpu)
 	u32 icrh = svm->vmcb->control.exit_info_1 >> 32;
 	u32 icrl = svm->vmcb->control.exit_info_1;
 	u32 id = svm->vmcb->control.exit_info_2 >> 32;
-	u32 index = svm->vmcb->control.exit_info_2 & 0xFF;
+	u32 index = svm->vmcb->control.exit_info_2 & 0x1FF;
 	struct kvm_lapic *apic = vcpu->arch.apic;
 
 	trace_kvm_avic_incomplete_ipi(vcpu->vcpu_id, icrh, icrl, id, index);
@@ -415,7 +498,7 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu *vcpu)
 		 * set the appropriate IRR bits on the valid target
 		 * vcpus. So, we just need to kick the appropriate vcpu.
 		 */
-		avic_kick_target_vcpus(vcpu->kvm, apic, icrl, icrh);
+		avic_kick_target_vcpus(vcpu->kvm, apic, icrl, icrh, index);
 		break;
 	case AVIC_IPI_FAILURE_INVALID_TARGET:
 		break;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH 2/2] KVM: SVM: Introduce trace point for the slow-path of avic_kic_target_vcpus
  2022-04-14  5:11 [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit
  2022-04-14  5:11 ` [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast() Suravee Suthikulpanit
@ 2022-04-14  5:11 ` Suravee Suthikulpanit
  2022-04-18 11:03   ` Maxim Levitsky
  2022-04-18 14:39 ` [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit
  2 siblings, 1 reply; 7+ messages in thread
From: Suravee Suthikulpanit @ 2022-04-14  5:11 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: pbonzini, mlevitsk, seanjc, joro, jon.grimm, wei.huang2,
	terry.bowman, Suravee Suthikulpanit

This can help identify potential performance issues when handles
AVIC incomplete IPI due vCPU not running.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
 arch/x86/kvm/svm/avic.c |  2 ++
 arch/x86/kvm/trace.h    | 20 ++++++++++++++++++++
 arch/x86/kvm/x86.c      |  1 +
 3 files changed, 23 insertions(+)

diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
index 92d8e0de1fb4..e5fb4931a2f1 100644
--- a/arch/x86/kvm/svm/avic.c
+++ b/arch/x86/kvm/svm/avic.c
@@ -440,6 +440,8 @@ static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
 	if (!avic_kick_target_vcpus_fast(kvm, source, icrl, icrh, index))
 		return;
 
+	trace_kvm_avic_kick_vcpu_slowpath(icrh, icrl, index);
+
 	/*
 	 * Wake any target vCPUs that are blocking, i.e. waiting for a wake
 	 * event.  There's no need to signal doorbells, as hardware has handled
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index e3a24b8f04be..de4762517569 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -1459,6 +1459,26 @@ TRACE_EVENT(kvm_avic_ga_log,
 		  __entry->vmid, __entry->vcpuid)
 );
 
+TRACE_EVENT(kvm_avic_kick_vcpu_slowpath,
+	    TP_PROTO(u32 icrh, u32 icrl, u32 index),
+	    TP_ARGS(icrh, icrl, index),
+
+	TP_STRUCT__entry(
+		__field(u32, icrh)
+		__field(u32, icrl)
+		__field(u32, index)
+	),
+
+	TP_fast_assign(
+		__entry->icrh = icrh;
+		__entry->icrl = icrl;
+		__entry->index = index;
+	),
+
+	TP_printk("icrh:icrl=%#08x:%08x, index=%u",
+		  __entry->icrh, __entry->icrl, __entry->index)
+);
+
 TRACE_EVENT(kvm_hv_timer_state,
 		TP_PROTO(unsigned int vcpu_id, unsigned int hv_timer_in_use),
 		TP_ARGS(vcpu_id, hv_timer_in_use),
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d0fac57e9996..c2da6c7516b0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12978,6 +12978,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_pi_irte_update);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_unaccelerated_access);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_incomplete_ipi);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_ga_log);
+EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_kick_vcpu_slowpath);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_apicv_accept_irq);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_vmgexit_enter);
 EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_vmgexit_exit);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast()
  2022-04-14  5:11 ` [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast() Suravee Suthikulpanit
@ 2022-04-14 19:21   ` Sean Christopherson
  2022-04-18 11:02   ` Maxim Levitsky
  1 sibling, 0 replies; 7+ messages in thread
From: Sean Christopherson @ 2022-04-14 19:21 UTC (permalink / raw)
  To: Suravee Suthikulpanit
  Cc: linux-kernel, kvm, pbonzini, mlevitsk, joro, jon.grimm,
	wei.huang2, terry.bowman

A drive-by comment on the shortlog, something like

  KVM: SVM: Use target APIC ID to complete AVIC IRQs when possible

is much more helpful, e.g. I had to read the entire changelog and most of the
code to find out what "fast" meant.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast()
  2022-04-14  5:11 ` [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast() Suravee Suthikulpanit
  2022-04-14 19:21   ` Sean Christopherson
@ 2022-04-18 11:02   ` Maxim Levitsky
  1 sibling, 0 replies; 7+ messages in thread
From: Maxim Levitsky @ 2022-04-18 11:02 UTC (permalink / raw)
  To: Suravee Suthikulpanit, linux-kernel, kvm
  Cc: pbonzini, seanjc, joro, jon.grimm, wei.huang2, terry.bowman

On Thu, 2022-04-14 at 00:11 -0500, Suravee Suthikulpanit wrote:
> Currently, an AVIC-enabled VM suffers from performance bottleneck
> when scaling to large number of vCPUs for I/O intensive workloads.
> 
> In such case, a vCPU often executes halt instruction to get into idle state
> waiting for interrupts, in which KVM would de-schedule the vCPU from
> physical CPU.
> 
> When AVIC HW tries to deliver interrupt to the halting vCPU, it would
> result in AVIC incomplete IPI #vmexit to notify KVM to reschedule
> the target vCPU into running state.
> 
> Investigation has shown the main hotspot is in the kvm_apic_match_dest()
> in the following call stack where it tries to find target vCPUs
> corresponded to the information in the ICRH/ICRL registers.
> 
>   - handle_exit
>     - svm_invoke_exit_handler
>       - avic_incomplete_ipi_interception
>         - kvm_apic_match_dest
> 
> However, AVIC provides hints in the #vmexit info, which can be used to
> retrieve the destination guest physical APIC ID.
> 
> In addition, since QEMU defines guest physical APIC ID to be the same as
> vCPU ID, it can be used to quickly identify the target vCPU to deliver IPI,
> and avoid the overhead from searching through all vCPUs to match the target
> vCPU.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  arch/x86/kvm/svm/avic.c | 91 +++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 87 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> index abcf761c0c53..92d8e0de1fb4 100644
> --- a/arch/x86/kvm/svm/avic.c
> +++ b/arch/x86/kvm/svm/avic.c
> @@ -351,11 +351,94 @@ void avic_ring_doorbell(struct kvm_vcpu *vcpu)
>  	put_cpu();
>  }
>  
> -static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
> -				   u32 icrl, u32 icrh)
> +/*
> + * A fast-path version of avic_kick_target_vcpus(), which attempts to match
> + * destination APIC ID to vCPU without looping through all vCPUs.
> + */
> +static int avic_kick_target_vcpus_fast(struct kvm *kvm, struct kvm_lapic *source,
> +				       u32 icrl, u32 icrh, u32 index)
>  {
> +	u32 dest, apic_id;
>  	struct kvm_vcpu *vcpu;
> +	int dest_mode = icrl & APIC_DEST_MASK;
> +	int shorthand = icrl & APIC_SHORT_MASK;
> +	struct kvm_svm *kvm_svm = to_kvm_svm(kvm);
> +	u32 *avic_logical_id_table = page_address(kvm_svm->avic_logical_id_table_page);
> +
> +	if (shorthand != APIC_DEST_NOSHORT)
> +		return -EINVAL;
> +
> +	/*
> +	 * The AVIC incomplete IPI #vmexit info provides index into
> +	 * the physical APIC ID table, which can be used to derive 
> +	 * guest physical APIC ID.
> +	 */
> +	if (dest_mode == APIC_DEST_PHYSICAL) {
> +		apic_id = index;
> +	} else {
> +		if (!apic_x2apic_mode(source)) {
> +			/* For xAPIC logical mode, the index is for logical APIC table. */
> +			apic_id = avic_logical_id_table[index] & 0x1ff;
> +		} else {
> +			/* For x2APIC logical mode, cannot leverage the index.
> +			 * Instead, calculate physical ID from logical ID in ICRH.
> +			 */
> +			int apic;
> +			int first = ffs(icrh & 0xffff);
> +			int last = fls(icrh & 0xffff);
> +			int cluster = (icrh & 0xffff0000) >> 16;
> +
> +			/*
> +			 * If the x2APIC logical ID sub-field (i.e. icrh[15:0]) contains zero
> +			 * or more than 1 bits, we cannot match just one vcpu to kick for
> +			 * fast path.
> +			 */
> +			if (!first || (first != last))
> +				return -EINVAL;
> +
> +			apic = first - 1;
> +			if ((apic < 0) || (apic > 15) || (cluster >= 0xfffff))
> +				return -EINVAL;
> +			apic_id = (cluster << 4) + apic;
> +		}
> +	}
> +
> +	/*
> +	 * Assuming vcpu ID is the same as physical apic ID,
> +	 * and use it to retrieve the target vCPU.
> +	 */
> +	vcpu = kvm_get_vcpu_by_id(kvm, apic_id);
> +	if (!vcpu)
> +		return -EINVAL;
> +
> +	if (apic_x2apic_mode(vcpu->arch.apic))
> +		dest = icrh;
> +	else
> +		dest = GET_XAPIC_DEST_FIELD(icrh);
> +
> +	/*
> +	 * Try matching the destination APIC ID with the vCPU.
> +	 */
> +	if (kvm_apic_match_dest(vcpu, source, shorthand, dest, dest_mode)) {
> +		vcpu->arch.apic->irr_pending = true;
> +		svm_complete_interrupt_delivery(vcpu,
> +						icrl & APIC_MODE_MASK,
> +						icrl & APIC_INT_LEVELTRIG,
> +						icrl & APIC_VECTOR_MASK);
> +		return 0;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
> +				   u32 icrl, u32 icrh, u32 index)
> +{
>  	unsigned long i;
> +	struct kvm_vcpu *vcpu;
> +
> +	if (!avic_kick_target_vcpus_fast(kvm, source, icrl, icrh, index))
> +		return;
>  
>  	/*
>  	 * Wake any target vCPUs that are blocking, i.e. waiting for a wake
> @@ -388,7 +471,7 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu *vcpu)
>  	u32 icrh = svm->vmcb->control.exit_info_1 >> 32;
>  	u32 icrl = svm->vmcb->control.exit_info_1;
>  	u32 id = svm->vmcb->control.exit_info_2 >> 32;
> -	u32 index = svm->vmcb->control.exit_info_2 & 0xFF;
> +	u32 index = svm->vmcb->control.exit_info_2 & 0x1FF;
>  	struct kvm_lapic *apic = vcpu->arch.apic;
>  
>  	trace_kvm_avic_incomplete_ipi(vcpu->vcpu_id, icrh, icrl, id, index);
> @@ -415,7 +498,7 @@ int avic_incomplete_ipi_interception(struct kvm_vcpu *vcpu)
>  		 * set the appropriate IRR bits on the valid target
>  		 * vcpus. So, we just need to kick the appropriate vcpu.
>  		 */
> -		avic_kick_target_vcpus(vcpu->kvm, apic, icrl, icrh);
> +		avic_kick_target_vcpus(vcpu->kvm, apic, icrl, icrh, index);
>  		break;
>  	case AVIC_IPI_FAILURE_INVALID_TARGET:
>  		break;



Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>

Best regards,
	Maxim Levitsky


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 2/2] KVM: SVM: Introduce trace point for the slow-path of avic_kic_target_vcpus
  2022-04-14  5:11 ` [PATCH 2/2] KVM: SVM: Introduce trace point for the slow-path of avic_kic_target_vcpus Suravee Suthikulpanit
@ 2022-04-18 11:03   ` Maxim Levitsky
  0 siblings, 0 replies; 7+ messages in thread
From: Maxim Levitsky @ 2022-04-18 11:03 UTC (permalink / raw)
  To: Suravee Suthikulpanit, linux-kernel, kvm
  Cc: pbonzini, seanjc, joro, jon.grimm, wei.huang2, terry.bowman

On Thu, 2022-04-14 at 00:11 -0500, Suravee Suthikulpanit wrote:
> This can help identify potential performance issues when handles
> AVIC incomplete IPI due vCPU not running.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
>  arch/x86/kvm/svm/avic.c |  2 ++
>  arch/x86/kvm/trace.h    | 20 ++++++++++++++++++++
>  arch/x86/kvm/x86.c      |  1 +
>  3 files changed, 23 insertions(+)
> 
> diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c
> index 92d8e0de1fb4..e5fb4931a2f1 100644
> --- a/arch/x86/kvm/svm/avic.c
> +++ b/arch/x86/kvm/svm/avic.c
> @@ -440,6 +440,8 @@ static void avic_kick_target_vcpus(struct kvm *kvm, struct kvm_lapic *source,
>  	if (!avic_kick_target_vcpus_fast(kvm, source, icrl, icrh, index))
>  		return;
>  
> +	trace_kvm_avic_kick_vcpu_slowpath(icrh, icrl, index);
> +
>  	/*
>  	 * Wake any target vCPUs that are blocking, i.e. waiting for a wake
>  	 * event.  There's no need to signal doorbells, as hardware has handled
> diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
> index e3a24b8f04be..de4762517569 100644
> --- a/arch/x86/kvm/trace.h
> +++ b/arch/x86/kvm/trace.h
> @@ -1459,6 +1459,26 @@ TRACE_EVENT(kvm_avic_ga_log,
>  		  __entry->vmid, __entry->vcpuid)
>  );
>  
> +TRACE_EVENT(kvm_avic_kick_vcpu_slowpath,
> +	    TP_PROTO(u32 icrh, u32 icrl, u32 index),
> +	    TP_ARGS(icrh, icrl, index),
> +
> +	TP_STRUCT__entry(
> +		__field(u32, icrh)
> +		__field(u32, icrl)
> +		__field(u32, index)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->icrh = icrh;
> +		__entry->icrl = icrl;
> +		__entry->index = index;
> +	),
> +
> +	TP_printk("icrh:icrl=%#08x:%08x, index=%u",
> +		  __entry->icrh, __entry->icrl, __entry->index)
> +);
> +
>  TRACE_EVENT(kvm_hv_timer_state,
>  		TP_PROTO(unsigned int vcpu_id, unsigned int hv_timer_in_use),
>  		TP_ARGS(vcpu_id, hv_timer_in_use),
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d0fac57e9996..c2da6c7516b0 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -12978,6 +12978,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_pi_irte_update);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_unaccelerated_access);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_incomplete_ipi);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_ga_log);
> +EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_avic_kick_vcpu_slowpath);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_apicv_accept_irq);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_vmgexit_enter);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_vmgexit_exit);

Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>

Best regards,
        Maxim Levitsky


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling
  2022-04-14  5:11 [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit
  2022-04-14  5:11 ` [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast() Suravee Suthikulpanit
  2022-04-14  5:11 ` [PATCH 2/2] KVM: SVM: Introduce trace point for the slow-path of avic_kic_target_vcpus Suravee Suthikulpanit
@ 2022-04-18 14:39 ` Suravee Suthikulpanit
  2 siblings, 0 replies; 7+ messages in thread
From: Suravee Suthikulpanit @ 2022-04-18 14:39 UTC (permalink / raw)
  To: linux-kernel, kvm
  Cc: pbonzini, mlevitsk, seanjc, joro, jon.grimm, wei.huang2, terry.bowman



On 4/14/22 12:11 PM, Suravee Suthikulpanit wrote:
> This series introduce a fast-path when handling AVIC incomplete IPI #vmexit
> for AVIC and x2AVIC, and introduce a new tracepoint for the slow-path
> processing.
> 
> Please note that the prereq of this series is:
>    [PATCH v2 00/12] Introducing AMD x2APIC Virtualization (x2AVIC) support
>    (https://lore.kernel.org/lkml/20220412115822.14351-2-suravee.suthikulpanit@amd.com/T/)
> 

Since x2AVIC stuff is still under development, and likely will need v3,
I will extract the logic for x2AVIC, and send out V2 of this series.
The support for x2AVIC will be send separately.

Regards,
Suravee

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-04-18 15:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-14  5:11 [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit
2022-04-14  5:11 ` [PATCH 1/2] KVM: SVM: Introduce avic_kick_target_vcpus_fast() Suravee Suthikulpanit
2022-04-14 19:21   ` Sean Christopherson
2022-04-18 11:02   ` Maxim Levitsky
2022-04-14  5:11 ` [PATCH 2/2] KVM: SVM: Introduce trace point for the slow-path of avic_kic_target_vcpus Suravee Suthikulpanit
2022-04-18 11:03   ` Maxim Levitsky
2022-04-18 14:39 ` [PATCH 0/2] KVM: SVM: Optimize AVIC incomplete IPI #vmexit handling Suravee Suthikulpanit

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).