| Message ID | 1476059023-33224-1-git-send-email-longpeng2@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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"). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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)) {
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(-)