I have successfully passed through a video card, network card, USB mouse, and USB keyboard to a MS Vista guest. That works well. I am trying to add another PCI device, such as a audio card or PCI USB hub, but I am running into a strange problem. When I plug the PCI audio (or USB card) to the motherboard. It makes it so that the PCI video card is no longer an "assignable device" (xm pci-list-assignable-devices doesn''t see it anymore, but previously I had passed it through successfully). Things I have thought to check. pciback (in proc) still owns the device. dmesg still shows the proper output, i.e. seizing device, interupt --> IRQ, device disabled, just like they should be. The problem at first glance, seems to be the fact that there are two devices on 03:XX.X The video card shows up as 03:02.0 and the next card plugged into the motherboard shows up as 03:00.0. The other devices (besides the video card) that I have successfully passed all had 00:XX.X, so when adding the second PCI card to the motherboard, that is the first time there are two 03:XX.X devices on the bus. I am using a relatively recent pull of xen-unstable with a 2.6.18.8-xen kernel from xenbits as well. Suggestions on how to debug further? Thanks in advance, Todd -- Todd Deshane http://todddeshane.net http://runningxen.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Todd, Can you attach the output log of 'lspci -tv' and 'lspci -xxx -vvv'? 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, -- Dexuan -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Todd Deshane Sent: 2008年10月10日 5:23 To: xen-devel mailing list Subject: [Xen-devel] Strange PCI Passthrough problem I have successfully passed through a video card, network card, USB mouse, and USB keyboard to a MS Vista guest. That works well. I am trying to add another PCI device, such as a audio card or PCI USB hub, but I am running into a strange problem. When I plug the PCI audio (or USB card) to the motherboard. It makes it so that the PCI video card is no longer an "assignable device" (xm pci-list-assignable-devices doesn't see it anymore, but previously I had passed it through successfully). Things I have thought to check. pciback (in proc) still owns the device. dmesg still shows the proper output, i.e. seizing device, interupt --> IRQ, device disabled, just like they should be. The problem at first glance, seems to be the fact that there are two devices on 03:XX.X The video card shows up as 03:02.0 and the next card plugged into the motherboard shows up as 03:00.0. The other devices (besides the video card) that I have successfully passed all had 00:XX.X, so when adding the second PCI card to the motherboard, that is the first time there are two 03:XX.X devices on the bus. I am using a relatively recent pull of xen-unstable with a 2.6.18.8-xen kernel from xenbits as well. Suggestions on how to debug further? Thanks in advance, Todd -- Todd Deshane http://todddeshane.net http://runningxen.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2008/10/9 Cui, Dexuan <dexuan.cui@intel.com>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@gmail.com]
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@intel.com>
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
2008/10/10 Cui, Dexuan <dexuan.cui@intel.com>> 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;What is the configuration in the guest config and xend etc. for this to work?> > 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? :-)I am already using all the normal PCI slots. The only slot I know have free is a PCI-e slot and the devices I am attempting to add are PCI.> Or, as a temporary workaround, you can use the attached patch to ignore the > FLR things though this is unsafe... >Do I even need the workaround patch? Or can I just do it with the proper config options, since I am trying to assign to the same guest.> > 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? >I don't really think the force_assign is intuitive, could you instead extend the xm pci-list-assignable-devices to print the possible/correct pci combinations and then you could have some special force option or the like that gets printed in this case with a warning about if you assign like that it is unsafe due to X. Cheers, Todd> > Comments are welcome. > > Thanks, > -- Dexuan > ________________________________ > > From: Todd Deshane [mailto:deshantm@gmail.com] > 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@intel.com> > 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 >-- Todd Deshane http://todddeshane.net http://runningxen.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2008/10/10 Cui, Dexuan <dexuan.cui@intel.com>:> 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.I applied the patch and was able to assign both device to the same guest fine.> 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?After applying the patch, I needed to hide the second card on the PCI bridge and then restart dom0, late binding could be used, but doesn''t the pci_force_assign need to apply to dom0/xend and not the domU guest config? xm pci-list-assignable-devices (after applying the patch), showed the two 03: device on the same line, which implied that they should be used on the same guest, but maybe this could be made more explicit? I think that the limitation of assigning the devices to the same domU is acceptable in many cases and should somehow be enabled out of the box. Even if you need to specify that it should happen with a xend config option etc. Cheers, Todd> > Comments are welcome. > > Thanks, > -- Dexuan > _______________________________________________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel