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
disable_FLR.patch
Description: disable_FLR.patch
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home