From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: co-assignment needs for PCI devices Date: Tue, 31 Mar 2009 08:10:07 +0100 Message-ID: <49D1DDEF.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dexuan Cui Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org c/s 18046 adds the requirement to co-assign PCI devices behind bridges/ PCIe functions on the same device when the (perhaps individual) device/ function intended to be assigned doesn't support FLR and doesn't sit on bus 0. For non-IOMMU environments (which are insecure anyway) this could be considered a regression, since passing through individual = devices/ functions didn't know such a restriction earlier. Also, being not really knowledgeable about all the differences between PCIe and PCI, I'd appreciate some clarification on why on PCIe it is possible and correct to do a secondary bus reset when targeting just the (PCIe) functions of a single device - to me this seems to imply that there's a one-device-per-non-root-bus restriction there. Thanks, Jan