WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH]vtd: Fix for irq bind failure after PCI attaching

On Thu, 27 Jan 2011, Zhang, Fengzhe wrote:
> Hi, Stefano,
> 
> Here is the calling graph that cause the bug:
> 
> unregister_real_device (ioemu)
>     |
>     +----> pt_msix_disable (ioemu)
>             |
>             +----> xc_domain_unbind_msi_irq (ioemu)
>             |       |
>             |       +----> do_domctl (xen) ----> arch_do_domctl (xen) ----> 
> pt_irq_destroy_bind_vtd (xen)
>             |              |
>             |              +----> unmap_domain_pirq_emuirq (xen)  //freed 
> pirq_to_emuirq
>             |
>             +----> xc_physdev_unmap_pirq (ioemu)
>                    |
>                    +----> do_physdev_op (xen) 
>                            |
>                            +----> physdev_unmap_pirq (xen)
>                                    |
>                                    +----> unmap_domain_pirq_emuirq (xen)  
> //found pirq_to_emuirq already freed, abort
>                                    |
>                                    +----> unmap_domain_pirq (xen)    //not 
> called
> 
> The code path you mentioned is not taken for VF dev as its ptdev->machine_irq 
> is 0.
> 

Thank you for the clarification. I think your patch is correct and
should be applied.


I was just wondering if it is possible to think of another scenario that
would trigger the same kind of bug calling several times
pt_reset_interrupt_and_io_mapping in ioemu, because it seems to me that
there is no xc_physdev_unmap_pirq call there if ptdev->machine_irq != 0.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel