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] Re-enable MSI support

To: 'Espen Skoglund' <espen.skoglund@xxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Re-enable MSI support
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 10 Dec 2008 21:37:37 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "wei.wang2@xxxxxxx" <wei.wang2@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 10 Dec 2008 05:38:08 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18751.43300.900610.363039@xxxxxxxxxxxxxxxxxx>
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: <E2263E4A5B2284449EEBD0AAB751098401C31CA5E9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18751.43300.900610.363039@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aclau1lp7YKPQEOdRiG7BB2ilm7QAgAD5xsA
Thread-topic: [Xen-devel] [PATCH] Re-enable MSI support
>From: Espen Skoglund
>Sent: Wednesday, December 10, 2008 7:34 PM
>
>[Yunhong Jiang]
>> This patch try to do some cleanup for these issues.
>> 1) The basic idea is to remove the pci_dev's lock, instead, we try
>>    to use the big pcidevs_lock to protect the whole pci_dev
>>    stuff. It including both pci_dev adding/removing, and also the
>>    assignment of the devices. We checked the code and seems there is
>>    no critical code path for this. We try to use fine-grained lock
>>    and seems the code will be very tricky.
>> 2) Split the pci_enable_msi into two step, firstly it will just
>>    construct the msi_desc through pci_enable_msi without holding the
>>    irq_desc lock, and then it will setup msi through setup_msi_irq
>>    with irq_desc holded.
>> 3) Change the iommu->lock and hd->mapping_lock to be irq_save. 
>> 4) Fix to some minor issues.
>
>> Now the lock sequence is: pcidevs_lock -> domai's event_lock ->
>> iommu's lock -> hvm_iommu's mapping_lock. The irq_desc's lock will
>> always be the last lock be hold for peformance consideration.
>
>So what exactly is it that pcidevs_lock is supposed to "protect" now?
>Does it indicate that someone is holding a reference to a pci_dev?
>Does it indicate that someone will modify some pci_dev?  Does it
>indicate that someone is messing around with interrupts or MSI
>descriptors?

I think it protects all above. As those operations are all rare, such a
big lock can avoid complex lock/unlock sequence regarding to different
paths to different resource of an assigned device.

>
>Regarding pci_enable_msi: Can you not get into race conditions with
>the splitup you're doing?  pci_enable_msi() does afterall poke around
>in the MSI capability record.
>
>       eSk

If I read it correctly, only one out of lock is to mask/unmask MSI
vector. MSI-X has per-vector mask dword, and thus no contention.
multiple-vector support for MSI is not supported yet. All other touch
to MSI/MSI-X capabilities are protected by that lock.

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