Re: [PATCH v12 3/3] x86, apicv: add virtual interrupt delivery support

[Gleb Natapov <gleb@redhat.com>]

On Thu, Jan 24, 2013 at 01:47:34PM +0000, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-01-24:
> > On Wed, Jan 23, 2013 at 10:47:26PM +0800, Yang Zhang wrote:
> >> From: Yang Zhang <yang.z.zhang@Intel.com>
> >> 
> >> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
> >> manually, which is fully taken care of by the hardware. This needs
> >> some special awareness into existing interrupr injection path:
> >> 
> >> - for pending interrupt, instead of direct injection, we may need
> >>   update architecture specific indicators before resuming to guest.
> >> - A pending interrupt, which is masked by ISR, should be also
> >>   considered in above update action, since hardware will decide
> >>   when to inject it at right time. Current has_interrupt and
> >>   get_interrupt only returns a valid vector from injection p.o.v.
> >> Signed-off-by: Kevin Tian <kevin.tian@intel.com>
> >> Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
> >> ---
> >>  arch/ia64/kvm/lapic.h           |    6 ++
> >>  arch/x86/include/asm/kvm_host.h |    7 ++ arch/x86/include/asm/vmx.h  
> >>     |   11 +++ arch/x86/kvm/irq.c              |   56 +++++++++++++++--
> >>  arch/x86/kvm/lapic.c            |  106 ++++++++++++++++++++++++-------
> >>  arch/x86/kvm/lapic.h            |   27 ++++++++ arch/x86/kvm/svm.c    
> >>           |   31 +++++++++ arch/x86/kvm/vmx.c              |  133
> >>  ++++++++++++++++++++++++++++++++++++--- arch/x86/kvm/x86.c            
> >>   |   11 +++- include/linux/kvm_host.h        |    3 +
> >>  virt/kvm/ioapic.c               |   39 +++++++++++ virt/kvm/ioapic.h  
> >>              |    4 + virt/kvm/irq_comm.c             |   25 +++++++
> >>  virt/kvm/kvm_main.c             |    5 ++ 14 files changed, 425
> >>  insertions(+), 39 deletions(-)
> >>
> >> +static void vmx_hwapic_vector_intercept_on_eoi(struct kvm_vcpu *vcpu,
> >> +					u32 vector, u64 *eoi_exit_bitmap)
> >> +{
> >> +	BUG_ON(vector > 255);
> >> +	__set_bit(vector, (unsigned long *)eoi_exit_bitmap);
> >Nothing that warrants this to be vmx callback is here.
> >> +}
> >> +
> >> +static void vmx_load_eoi_exitmap(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
> >> +{
> >> +	vmcs_write64(EOI_EXIT_BITMAP0, eoi_exit_bitmap[0]);
> >> +	vmcs_write64(EOI_EXIT_BITMAP1, eoi_exit_bitmap[1]);
> >> +	vmcs_write64(EOI_EXIT_BITMAP2, eoi_exit_bitmap[2]);
> >> +	vmcs_write64(EOI_EXIT_BITMAP3, eoi_exit_bitmap[3]);
> >> +}
> >> +
> >> +static void vmx_update_eoi_exitmap(struct kvm_vcpu *vcpu)
> >> +{
> >> +	u64 eoi_exit_bitmap[4];
> >> +
> >> +	/* clear eoi exit bitmap */
> >> +	memset(eoi_exit_bitmap, 0, 32);
> >> +
> >> +	kvm_ioapic_calculate_eoi_exitmap(vcpu, eoi_exit_bitmap);
> >> +	vmx_load_eoi_exitmap(vcpu, eoi_exit_bitmap);
> >> +}
> >Same as above. Why is this vmx callback?
> Why this callback is redundant? We can remove vmx_hwapic_vector_intercept_on_eoi, but this callback is necessary.
> 
We try to put only necessary things in to the callback and generic
things into common code. vmx_load_eoi_exitmap() is the only thing that
is vmx specific, so make load_eoi_exitmap() callback please that does
just that.

--
			Gleb.