Re: [Xen-devel] [xen-unstable test] 17716: regressions - FAIL

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Jan Beulich wrote on 2013-04-19:
>>>> On 19.04.13 at 10:38, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>>> On 18.04.13 at 18:12, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
>>> flight 17716 xen-unstable real [real]
>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/17716/
>>> 
>>> Regressions :-(
>>> 
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-amd64-xl-qemut-win7-amd64  8 guest-saverestore fail REGR.
>>>  vs. 17714 test-amd64-amd64-xl-qemuu-winxpsp3  8 guest-saverestore  
>>>  fail REGR. vs. 17713 test-amd64-i386-xend-winxpsp3  8
>>>  guest-saverestore        fail REGR. vs. 17714
>>>  test-amd64-amd64-xl-win7-amd64  8 guest-saverestore       fail REGR.
>>>  vs. 17714 test-amd64-i386-xl-win7-amd64  8 guest-saverestore       
>>>  fail REGR. vs. 17714 test-amd64-i386-xl-qemut-win7-amd64  8
>>>  guest-saverestore  fail REGR. vs. 17714 test-amd64-amd64-xl-winxpsp3 
>>>  8 guest-saverestore         fail REGR. vs. 17714
>>>  test-amd64-amd64-xl-qemut-winxpsp3  8 guest-saverestore   fail REGR.
>>>  vs. 17714 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 10
>>>  guest-saverestore.2 fail REGR. vs. 17714
>>>  test-amd64-i386-xend-qemut-winxpsp3  8 guest-saverestore  fail REGR.
> vs. 17714
>> 
>> There are floods of (host side!) APIC errors in the logs, and it
>> the posted interrupt series seems the most likely reason for
>> this. I'll try to look into this in more detail, but input from you
>> on possible reasons would be greatly appreciated. Of course I
>> can't fully exclude that with the little bit of cleanup I did to your
>> patches I screwed up something...
> 
> So I guess its the send_IPI_mask() here:
> 
> static void __vmx_deliver_posted_interrupt(struct vcpu *v)
> {
>     bool_t running = v->is_running;
>     
>     vcpu_unblock(v);
>     if ( running && (in_irq() || (v != current)) )
>     {
>         unsigned int cpu = v->processor;
>         
>         if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, &softirq_pending(cpu))
>              && (cpu != smp_processor_id()) )
>             send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
>     }
> }
> 
> Which is supposed to be unreachable on systems that don't
> support posted interrupts, but
> 
>     if ( cpu_has_vmx_posted_intr_processing )
>         alloc_direct_apic_vector(&posted_intr_vector,
> event_check_interrupt);
>     else
>     {
>         hvm_funcs.deliver_posted_intr = NULL;
>         hvm_funcs.sync_pir_to_irr = NULL;
>     }
> adjusts the wrong pointers because of the subsequent
> 
>     return &vmx_function_table;
> Hence I guess the below fix is needed.
> 
> Jan
> 
> VMX: adjust correct table when there's no posted interrupt support
> 
> The caller of start_vmx() will overwrite hvm_funcs, so there's no point
> in adjusting that table in start_vmx().
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1587,8 +1587,8 @@ struct hvm_function_table * __init start
>          alloc_direct_apic_vector(&posted_intr_vector,
> event_check_interrupt);
>      else
>      {
> -        hvm_funcs.deliver_posted_intr = NULL;
> -        hvm_funcs.sync_pir_to_irr = NULL;
> +        vmx_function_table.deliver_posted_intr = NULL;
> +        vmx_function_table.sync_pir_to_irr = NULL;
>      }
>      
>      setup_vmcs_dump();
>

Acked.

Best regards,
Yang


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