Messages in this thread | | | Date | Tue, 11 Oct 2016 20:23:37 +0200 | From | Radim Krčmář <> | Subject | Re: [PATCH] kvm: x86: correct the misleading comment in vmx_handle_external_intr |
| |
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.
| |