From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: co-assignment needs for PCI devices Date: Tue, 31 Mar 2009 08:57:43 +0100 Message-ID: <49D1E917.76E4.0078.0@novell.com> References: <49D1DDEF.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: 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 >>> "Cui, Dexuan" 31.03.09 09:48 >>> >Jan Beulich wrote: >> 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. >According to VT-d spec (section 3.6.1: Identifying Origination of DMA = Requests), PCI devices behind the same uppermost PCI/PCI-X >bridge must be co-assigned to the same guest. PCIe devices have not such = a constraint. > >FLR (Functional Level Reset) is used to quiesce an assigned device when = we destroy a guest or we detach the device from the guest. >If a PCIe device has no standard FLR capability, we'll try to use = SecondaryBusReset as a way to do FLR. Unluckily, >SecondaryBusReset resets all the devices behind the bridge, so for a = multi-function PCIe device without FLR capability, we require >they have to be co-assigned to the same guest -- certainly this is only = for iommu case and for non-iommu case this requirement may >be not proper and we shoud fix it... But - for the sake of my education, if you forgive - you didn't answer = whether there is a one-device-per-secondary-bus restriction on PCIe... Thanks, Jan