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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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();




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