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

[Xen-devel] Re: [PATCH][RFC] fix some spinlock issues in vmsi

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH][RFC] fix some spinlock issues in vmsi
From: Qing He <qing.he@xxxxxxxxx>
Date: Fri, 6 Mar 2009 17:21:12 +0800
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Kouya Shimura <kouya@xxxxxxxxxxxxxx>
Delivery-date: Fri, 06 Mar 2009 01:20:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5D68F2A.4482%keir.fraser@xxxxxxxxxxxxx>
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: <20090306053117.GA23417@ub-qhe2> <C5D68F2A.4482%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.17+20080114 (2008-01-14)
On Fri, 2009-03-06 at 16:28 +0800, Keir Fraser wrote:
> On 06/03/2009 05:31, "Qing He" <qing.he@xxxxxxxxx> wrote:
> 
> > A similar problem also exists in msixtbl_write/msixtbl_read. Currently,
> > these functions access the mapped msix table using the pointer stored
> > in pci_dev, and when pci_dev is removed without the knowledge of the
> > guest, pci_dev alongside the fixmaps will be removed and this
> > definitely will frustrate these functions. Unfortunately, adding
> > spinlocks to msixtbl_{read,write} seems quite expensive, especially for
> > multiple guest threads, that's why RCU based lock is used here. For a
> > completely secure handling of this, maybe we need a less brute,
> > asynchronous pci_remove hypercall or something.
> 
> Add the locks, making it correct. Then optimise later as necessary, using
> RCU or (perhaps easier) just smaller locks: Per MSI-X or per-pci-dev or
> whatever. Throwing in racey code condemns us to subtle races forever more.

Ok, I'll make a patch to use the locks.

Do you think it's ok to assume that guest has already free the device
when calling remove_pci_device on hotplugging?

Thanks,
Qing

> 
>  -- Keir
> 
> 

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