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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH]vtd: Fix for irq bind failure after PCI attaching 32 times
From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Date: Thu, 24 Feb 2011 17:41:20 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>, "Zhang, Fengzhe" <fengzhe.zhang@xxxxxxxxx>
Delivery-date: Thu, 24 Feb 2011 17:42:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1102031448520.7277@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1A42CE6F5F474C41B63392A5F80372B231F6DFF6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1101261107560.7277@kaball-desktop> <1A42CE6F5F474C41B63392A5F80372B231F6E499@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1102021656530.7277@kaball-desktop> <alpine.DEB.2.00.1102031448520.7277@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvDthdLLXpEhhKiQTqHE8VRdRHxGAQ1Xt9A
Thread-topic: [Xen-devel] [PATCH]vtd: Fix for irq bind failure after PCI attaching 32 times
>        |                           +--> iommu_update_ire_from_msi
>        |                               (should clean the vtd binding, like 
> pt_irq_destroy_bind_vtd)

Stefano, iommu_update_ire_from_msi() maps to 
intremap.c/msi_msg_write_remap_rte() with vt-d hardware.  This function 
strictly deals with VT-d interrupt remapping HW related tasks.  It does not do 
any irq cleanup for xen.

Allen

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Stefano Stabellini
Sent: Thursday, February 03, 2011 7:23 AM
To: Stefano Stabellini
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Zhang, Xiantao; Zhang, Fengzhe
Subject: RE: [Xen-devel] [PATCH]vtd: Fix for irq bind failure after PCI 
attaching 32 times

On Wed, 2 Feb 2011, Stefano Stabellini wrote:
> 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.
> 
> It has just occurred to me that all this only happens with guest
> cooperation: unregister_real_device is called on pci hotplug in response
> to guest's action.
> That means that a guest that doesn't support pci hot-unplug (or a
> malicious guest) won't do anything in response to the acpi SCI interrupt
> we send, therefore unregister_real_device will never be called and we
> will be leaking MSIs in the host!
> 
> Of course we could solve it adding a new xenstore command to qemu that
> calls unregister_real_device directly, but it seems to me that relying
> on qemu to free some hypervisor/dom0 resources is not a good idea.
> 
> Xen knows all the pirq remapped to this domain, so wouldn't it be
> possible for Xen to call pt_irq_destroy_bind_vtd and physdev_unmap_pirq
> on domain_kill?
> I think that Xen shouldn't leak pirqs no matter what the toolstack or
> qemu do.
> 

actually it looks like xen is cleaning up after itself:

arch_domain_destroy
        |
        +--> pci_release_devices
        |            |
        |            +--> pci_cleanup_msi
        |                   |
        |                   +--> msi_free_irq
        |                           |
        |                           +--> iommu_update_ire_from_msi
        |                               (should clean the vtd binding, like 
pt_irq_destroy_bind_vtd)
        |            
        |            
        +--> free_domain_pirqs
                     |
                     +--> unmap_domain_pirq


so it doesn't actually matter if the guest supports pci hotplug or not,
because if it doesn't, xen won't leak any resources anyway.
Am I right? Could you please confirm this?

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

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