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] Strange PCI Passthrough problem

To: "'deshantm@xxxxxxxxx'" <deshantm@xxxxxxxxx>, 'Keir Fraser' <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Strange PCI Passthrough problem
From: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
Date: Fri, 10 Oct 2008 13:30:48 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: 'xen-devel mailing list' <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 09 Oct 2008 22:32:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1e16a9ed0810092101g20f047bat1a8312ff500ef5bd@xxxxxxxxxxxxxx>
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: <1e16a9ed0810091422q1af5fd64xa8fbaed18d1e17d9@xxxxxxxxxxxxxx> <F4AE3CDE26E0164D9E990A34F2D4E0DF08A5F5427C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1e16a9ed0810092101g20f047bat1a8312ff500ef5bd@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckqjO1Qdv3icehnTcyAL5p+R5YlNwAB6Mrw
Thread-topic: [Xen-devel] Strange PCI Passthrough problem
Hi Todd,
According to the logs, we can see the 03:00.0 and 03:02.0 are behind the same 
bridge, and both PCI devices lack the proper standard FLR capabilities.
So currently in xend, the policy under this situation (sure, this limit is not 
nice...) is:
we can choose to assign both devices to the same guest;
or,
we can assign either device to a guest and the other becomes un-assignable 
temporarily for another guest.

Looks your motherboard has some other available slots? Maybe you can try to 
insert the device to them? :-)
Or, as a temporary workaround, you can use the attached patch to ignore the FLR 
things though this is unsafe...

For the long run, should we add a bool parameter, like 'pci_force_assign', in 
guest config file? If the end user sets the paramter to true, under such a 
situation, if needed, we ignore the current policy and try to use the unsafe 
D-state method (if available) to do FLR?

Comments are welcome.

Thanks,
-- Dexuan
________________________________

From: Todd Deshane [mailto:deshantm@xxxxxxxxx]
Sent: 2008年10月10日 12:02
To: Cui, Dexuan
Cc: xen-devel mailing list
Subject: Re: [Xen-devel] Strange PCI Passthrough problem

2008/10/9 Cui, Dexuan <dexuan.cui@xxxxxxxxx>
        Hi Todd,
        Can you attach the output log of 'lspci -tv' and 'lspci -xxx -vvv'?

Attached.

        I'm afraid you meet with the co-assignment limit.
        If a device(including multi-function device) hasn't a proper standard 
FLR method, we have to use the SecondaryBusReset as a FLR method, so we require 
the co-assignment.
        You can refer to 
http://xenbits.xensource.com/xen-unstable.hg?rev/e61978c24d84 for details.

Thanks for the information.

Let me know if there is anything else I can do.

Cheers,
Todd

Attachment: disable_FLR.patch
Description: disable_FLR.patch

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