Re: [Xen-devel] Xen-unstable: Xen panic when shutting down HVM guest with PCI passthrough: RIP: e008:[<ffff82d0801099b1>] evtchn_move_pirqs+0x90/0xbf

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.06.14 at 10:15, <linux@xxxxxxxxxxxxxx> wrote:
>> Hmm, does the following patch fix it?
> 
> 
>> Juergen
> 
>> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
>> index c174c41..3ea9fc8 100644
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -297,7 +297,8 @@ int sched_move_domain(struct domain *d, struct 
>> cpupool *c)
>>           spin_unlock_irq(lock);
> 
>>           v->sched_priv = vcpu_priv[v->vcpu_id];
>> -        evtchn_move_pirqs(v);
> +        if ( !d->>is_dying )
>> +            evtchn_move_pirqs(v);
> 
>>           new_p = cpumask_cycle(new_p, c->cpu_valid);
> 
> Hi JÃrgen,
> 
> Tried that one, it prevents the host panic, but immediately after i do get 
> a:
> 
> [  658.222311] irq 16: nobody cared (try booting with the "irqpoll" option)
> [  658.229069] CPU: 0 PID: 17104 Comm: smtp Not tainted 
> 3.15.0-rc8-20140602-net-xendev-bt-mq+ #1
> [  658.235996] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS 
> V1.8B1 09/13/2010
> [  658.243234]  ffff880054b00718 ffff88005f603d98 ffffffff81b93243 
> ffff88002e4e9330
> [  658.250342]  ffff880054b00690 ffff88005f603dc8 ffffffff8112306d 
> ffff88005f603dc8
> [  658.257411]  ffff880054b00690 0000000000000010 0000000000000000 
> ffff88005f603e18
> [  658.264362] Call Trace:
> [  658.271128]  <IRQ>  [<ffffffff81b93243>] dump_stack+0x46/0x58
> [  658.278096]  [<ffffffff8112306d>] __report_bad_irq+0x3d/0xe0
> [  658.285175]  [<ffffffff8112355f>] note_interrupt+0x1bf/0x210
> [  658.292210]  [<ffffffff81120ca5>] handle_irq_event_percpu+0xb5/0x1e0
> [  658.299135]  [<ffffffff81120e18>] handle_irq_event+0x48/0x70
> [  658.306032]  [<ffffffff8112411f>] ? handle_fasteoi_irq+0x2f/0x150
> [  658.312935]  [<ffffffff8112417c>] handle_fasteoi_irq+0x8c/0x150
> [  658.319847]  [<ffffffff811204f2>] generic_handle_irq+0x22/0x40
> [  658.326627]  [<ffffffff8157dfb7>] evtchn_fifo_handle_events+0x137/0x140
> [  658.333370]  [<ffffffff8157aef0>] __xen_evtchn_do_upcall+0x50/0xa0
> [  658.340061]  [<ffffffff8157cc37>] xen_evtchn_do_upcall+0x37/0x50
> [  658.346575]  [<ffffffff81b9ff5e>] xen_do_hypervisor_callback+0x1e/0x30
> [  658.353214]  <EOI>
> [  658.353264] handlers:
> [  658.366234] [<ffffffff819a2440>] azx_interrupt
> [  658.372806] Disabling IRQ #16
> 
> Which could be related ?

evtchn_move_pirqs() is an entirely optional thing, trying to keep the
IRQs at CPUs where they would also get serviced. So from an
abstract pov making the call conditional upon an alive domain should
be unrelated. Otoh I suppose you would have told us if with the
commit reverted that Andrew suggested you also saw this...

Is the passed through device also sitting on IRQ 16 (the one getting
disabled)? In which case the question would be whether the passed
through device gets properly shut down when the guest terminates.

Jan

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