RE: [Xen-devel] Strange PCI Passthrough problem

["Cui, Dexuan" <dexuan.cui@xxxxxxxxx>]

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