All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr
@ 2016-10-10  0:23 Longpeng(Mike)
  2016-10-11 18:23 ` Radim Krčmář
  0 siblings, 1 reply; 4+ messages in thread
From: Longpeng(Mike) @ 2016-10-10  0:23 UTC (permalink / raw)
  To: pbonzini, rkrcmar, tglx, mingo, hpa, x86
  Cc: kvm, linux-kernel, zhaoshenglong, richard.weiyang, Longpeng(Mike)

Since Paolo has removed irq-enable-operation in vmx_handle_external_intr
(KVM: x86: use guest_exit_irqoff), the original comment about the IF bit
in rflags is incorrect now.

Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
---
 arch/x86/kvm/vmx.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index cf1b16d..9fa3c76 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8647,9 +8647,12 @@ static void vmx_handle_external_intr(struct kvm_vcpu *vcpu)
 	register void *__sp asm(_ASM_SP);
 
 	/*
-	 * If external interrupt exists, IF bit is set in rflags/eflags on the
-	 * interrupt stack frame, and interrupt will be enabled on a return
-	 * from interrupt handler.
+	 * If external interrupt exists, fakes an interrupt stack and jump to
+	 * idt table to let real handler to handle it. Because most of bits in
+	 * rflags are cleared when VM exit(Intel SDM volum 3, chapter 27.5.3),
+	 * the IF bit is 0 in rflags on the interrupt stack frame, so interrupt
+	 * is still disabled when return from the irq handler, but it will be
+	 * enabled later by the caller.
 	 */
 	if ((exit_intr_info & (INTR_INFO_VALID_MASK | INTR_INFO_INTR_TYPE_MASK))
 			== (INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR)) {
-- 
2.7.4

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

* Re: [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr
  2016-10-10  0:23 [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr Longpeng(Mike)
@ 2016-10-11 18:23 ` Radim Krčmář
  2016-10-12  1:15   ` Longpeng (Mike)
  0 siblings, 1 reply; 4+ messages in thread
From: Radim Krčmář @ 2016-10-11 18:23 UTC (permalink / raw)
  To: Longpeng(Mike)
  Cc: pbonzini, tglx, mingo, hpa, x86, kvm, linux-kernel,
	zhaoshenglong, richard.weiyang

2016-10-10 08:23+0800, Longpeng(Mike):
> Since Paolo has removed irq-enable-operation in vmx_handle_external_intr
> (KVM: x86: use guest_exit_irqoff), the original comment about the IF bit
> in rflags is incorrect now.
> 
> Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
> ---
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> @@ -8647,9 +8647,12 @@ static void vmx_handle_external_intr(struct kvm_vcpu *vcpu)
>  	register void *__sp asm(_ASM_SP);
>  
>  	/*
> -	 * If external interrupt exists, IF bit is set in rflags/eflags on the
> -	 * interrupt stack frame, and interrupt will be enabled on a return
> -	 * from interrupt handler.

Good catch, thanks.
We want to change it, but I think that the new comment is an overkill.

I am generally not a fan of code comments that describe what the code
does; code speaks for itself and it is better to fix the code, e.g.
split into well named functions, instead of duplicating it.

> +	 * If external interrupt exists, fakes an interrupt stack and jump to
> +	 * idt table to let real handler to handle it.

This is the duplication I was talking about.  If the corresponding part
of the code is not obvious, it would be better to rework it instead.

>  	                                               Because most of bits in
> +	 * rflags are cleared when VM exit(Intel SDM volum 3, chapter 27.5.3),
> +	 * the IF bit is 0 in rflags on the interrupt stack frame, so interrupt
> +	 * is still disabled when return from the irq handler, but it will be
> +	 * enabled later by the caller.

This part is acceptable as it gives a new information code, yet the
function does not modify flags, which makes it unremarkable.
And dependencies on the caller would be better described in a header
(if we cannot express them well in the code).

The most comment-worthy thing about this function is the reason why we
execute the interrupt handler manually, i.e. the dependency on
VM_EXIT_ACK_INTR_ON_EXIT, but that is easy to tell from the commit
message and convenient access to git history is essential in a workflow,
so providing a leeway could be counter-productive.

I would go with no comment for now.

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

* Re: [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr
  2016-10-11 18:23 ` Radim Krčmář
@ 2016-10-12  1:15   ` Longpeng (Mike)
  2016-10-12 14:05     ` Radim Krčmář
  0 siblings, 1 reply; 4+ messages in thread
From: Longpeng (Mike) @ 2016-10-12  1:15 UTC (permalink / raw)
  To: Radim Krčmář
  Cc: pbonzini, tglx, mingo, hpa, x86, kvm, linux-kernel,
	zhaoshenglong, richard.weiyang

Hi Radim,

On 2016/10/12 2:23, Radim Krčmář wrote:

> This part is acceptable as it gives a new information code, yet the
> function does not modify flags, which makes it unremarkable.
> And dependencies on the caller would be better described in a header
> (if we cannot express them well in the code).
> 
> The most comment-worthy thing about this function is the reason why we
> execute the interrupt handler manually, i.e. the dependency on
> VM_EXIT_ACK_INTR_ON_EXIT, but that is easy to tell from the commit
> message and convenient access to git history is essential in a workflow,
> so providing a leeway could be counter-productive.
> 
> I would go with no comment for now.
> 
> .
> 

Thanks for your patience, and your advice is useful for me.

In addition, the comment below is misleading too, hope you can fix it
simultaneously.

	/* Interrupt is enabled by handle_external_intr() */
	kvm_x86_ops->handle_external_intr(vcpu);

-- 
Regards,
Longpeng(Mike)

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

* Re: [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr
  2016-10-12  1:15   ` Longpeng (Mike)
@ 2016-10-12 14:05     ` Radim Krčmář
  0 siblings, 0 replies; 4+ messages in thread
From: Radim Krčmář @ 2016-10-12 14:05 UTC (permalink / raw)
  To: Longpeng (Mike)
  Cc: pbonzini, tglx, mingo, hpa, x86, kvm, linux-kernel,
	zhaoshenglong, richard.weiyang

2016-10-12 09:15+0800, Longpeng (Mike):
> On 2016/10/12 2:23, Radim Krčmář wrote:
>> This part is acceptable as it gives a new information code, yet the
>> function does not modify flags, which makes it unremarkable.
>> And dependencies on the caller would be better described in a header
>> (if we cannot express them well in the code).
>> 
>> The most comment-worthy thing about this function is the reason why we
>> execute the interrupt handler manually, i.e. the dependency on
>> VM_EXIT_ACK_INTR_ON_EXIT, but that is easy to tell from the commit
>> message and convenient access to git history is essential in a workflow,
>> so providing a leeway could be counter-productive.
>> 
>> I would go with no comment for now.
> 
> Thanks for your patience, and your advice is useful for me.

I appreciate the patch, I just didn't want to repeat the same mistake
that you were fixing in the patch, which made me go into rambling mode.

Please send v2 with a simpler code comment (or no comment).
And you are more than welcome to improve the code even further!

> In addition, the comment below is misleading too, hope you can fix it
> simultaneously.
> 
> 	/* Interrupt is enabled by handle_external_intr() */
> 	kvm_x86_ops->handle_external_intr(vcpu);

Yep, this comment should have been expressed in a function name.
Paolo already fixed it in 1a6982353db9 ("KVM: x86: remove stale
comments").

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

end of thread, other threads:[~2016-10-12 14:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-10  0:23 [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr Longpeng(Mike)
2016-10-11 18:23 ` Radim Krčmář
2016-10-12  1:15   ` Longpeng (Mike)
2016-10-12 14:05     ` Radim Krčmář

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.