[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Strange PCI Passthrough problem


  • To: "Cui, Dexuan" <dexuan.cui@xxxxxxxxx>
  • From: "Todd Deshane" <deshantm@xxxxxxxxx>
  • Date: Fri, 10 Oct 2008 10:01:26 -0400
  • Cc: xen-devel mailing list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 10 Oct 2008 07:01:56 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:references; b=ETa83o1tYELa6LEGoqeie+z8Hn6unoo6goUfba9Ml/m3Qs1vkubXOLKBDPdVVAIIRM yiL6t6LmeGACj37irIeh9jJMAwQE4eSAuIFuz4muspBrIsoxwDe6W1ZF2eAdR+x0Vy1X iiHA6rsk9SgWlxF0IIx1n6EkN6WLh9wY7F2sI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>



2008/10/10 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;

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@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



--
Todd Deshane
http://todddeshane.net
http://runningxen.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.