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
|
Home