[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: "Li, Jiongxi" <jiongxi.li@xxxxxxxxx>
  • Date: Thu, 13 Sep 2012 10:13:20 +0000
  • Accept-language: en-US
  • Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 13 Sep 2012 10:13:47 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHNjBs0nmuHFTegw0a4yZ6YMxWq9ZeIE82Q
  • Thread-topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery

A new patch is sent out according to review comment.
Also please see my comment interlaced

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, September 06, 2012 6:35 PM
> To: Li, Jiongxi
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@xxxxxxxxx> wrote:
> >> > +/*
> >> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> >> > +used
> >> > + * to handle EOI-induced VM exit
> >> > + */
> >> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> >> > +vector) {
> >> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> >> > +
> >> > +    if ( vlapic_test_and_clear_vector(vector,
> >> > + &vlapic->regs->data[APIC_TMR]) )
> >>
> >> Why test_and_clear rather than just test?
> > While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function
> > won't be called( 'vlapic_EOI_set' also has the test and clear call). '
> 
> Ah, okay.
> 
> >> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
> >> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012
> +0800
> >> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
> >> >              goto out;
> >> >
> >> >          intblk = hvm_interrupt_blocked(v, intack);
> >> > -        if ( intblk == hvm_intblk_tpr )
> >> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> >> >          {
> >> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> >> > -            ASSERT(intack.source == hvm_intsrc_lapic);
> >> > -            tpr_threshold = intack.vector >> 4;
> >> > -            goto out;
> >> > +            /* Set "Interrupt-window exiting" for ExtINT */
> >> > +            if ( (intblk != hvm_intblk_none) &&
> >> > +                 ( (intack.source == hvm_intsrc_pic) ||
> >> > +                 ( intack.source == hvm_intsrc_vector) ) )
> >> > +            {
> >> > +                enable_intr_window(v, intack);
> >> > +                goto out;
> >> > +            }
> >> > +
> >> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK )
> >> > +            {
> >> > +                if ( (intack.source == hvm_intsrc_pic) ||
> >> > +                     (intack.source == hvm_intsrc_nmi) ||
> >> > +                     (intack.source == hvm_intsrc_mce) )
> >> > +                    enable_intr_window(v, intack);
> >> > +
> >> > +                goto out;
> >> > +            }
> >> >          }
> >> > +        else
> >> > +        {
> >> > +            if ( intblk == hvm_intblk_tpr )
> >> > +            {
> >> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> >> > +                ASSERT(intack.source == hvm_intsrc_lapic);
> >> > +                tpr_threshold = intack.vector >> 4;
> >> > +                goto out;
> >> > +            }
> >> >
> >> > -        if ( (intblk != hvm_intblk_none) ||
> >> > -             (__vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK) )
> >> > -        {
> >> > -            enable_intr_window(v, intack);
> >> > -            goto out;
> >> > +            if ( (intblk != hvm_intblk_none) ||
> >> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK) )
> >> > +            {
> >> > +                enable_intr_window(v, intack);
> >> > +                goto out;
> >> > +            }
> >> >          }
> >>
> >> If you made the above and if()/else if() series, some of the
> >> differences
> > would go
> >> away, making the changes easier to review.
> > I can't quite understand you here.
> > The original code looked like:
> > if (a)
> > {}
> > if (b)
> > {}
> > And my change as follow:
> > if ( cpu_has_vmx_virtual_intr_delivery ) { } else {
> >   if (a)
> >   {}
> >   if (b)
> >   {}
> > }
> > How should I adjust the code?
> 
> Considering that the original could already have been written with 
> if/else-if, I
> was suggesting to expand this to your addition:
> 
> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
>   {}
> else if (b)
>   {}
> 
> which will avoid any (indentation only) changes past the first of the two 
> else-if-s.
> Plus it would make the logic of the code more clear, at once likely making
> apparent that there'll now be quite a few "goto out"-s that ought to be check
> for being replaceable by fewer instances of them placed slightly differently.
It is a good suggestion. But the original code is two parallel if() case, not 
the if/else-if case, and can't be changed to if/else-if case, so I just keep 
the original code here. :)

> 
> >> > +#define UPDATE_EOI_EXITMAP(v, e)
> {                             \
> >> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> >>
> >> Here and elsewhere - do you really need locked accesses?
> > Do you mean using the '__test_and_set_bit' ?
> 
> Yes, if suitable.
Since the parameter may also be changed in 'vlapic_set_irq' function, and that 
function may be called asynchronously, so a lock is needed here.

> >> Furthermore, here and in other places you fail to write the upper
> >> halves for 32-bit, yet you also don't disable the code for 32-bit afaics.
> > OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
> >   __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) #ifdef
> > __i386__
> >   __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
> > #endif
> 
> Something along those lines, yes.
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.