From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: RE: Xen enviroment consultation Date: Tue, 24 May 2011 09:54:53 -0400 Message-ID: <20110524135453.GC10926@dumpdata.com> References: <20110520151000.GB10691@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Fan, Huaxiang" Cc: "xen-devel@lists.xensource.com" , "xen-users@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Mon, May 23, 2011 at 08:54:19AM +0000, Fan, Huaxiang wrote: > Hi Konrad, > Thanks, the problem solved when I pass in 'iommu=soft' in the PV guests. Could you elaborate on the link between this option and the problem? You mean why you need 'iommu=soft' when doing PCI passthrough in PV guests? I would suggest you google for Xen SWIOTLB. I probably wrote the explanation in one of those links - but I don't remember which one. > > And this option also raised another minor issue. For example, I have 4 domus, and the PCI passthru situation as below: > Domu_name passthru_pci_number_in_dom0 > 1 04:00.0 04:00.1 > 2 02:00.0 02:00.1 > 3 01:00.1 > 4 > > I passed in 'iommu=soft' in 1,2,3 domu. The order I should boot the domus is 1,2,3,4. Otherwise, the domu might fail to boot due to the error: > Pciback 0000:04:00.1: device has been assigned to another domain! Over-writing the ownership, but beware. Looks like a bug in the pciback code. It somehow things that you had 04:00.1 assigned to another domain and hadn't cleaned it up probably. For right I would ignore that - as it is not failing the bootup - just warning you. And are you using xen-pciback.hide as an option to "hide" the devices from Dom0?