From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Issue with PCI-passthrough and pvops Date: Wed, 19 Oct 2011 10:10:32 -0400 Message-ID: <20111019141032.GB8033@phenom.dumpdata.com> References: <1318865791.25056.28.camel@Palantir> <20111017164020.GE19684@phenom.dumpdata.com> <1318982052.2997.19.camel@Palantir> <20111019011028.GA19302@phenom.dumpdata.com> <1319010037.11016.66.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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: Dario Faggioli Cc: xen-devel , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Wed, Oct 19, 2011 at 03:46:26PM +0200, Dario Faggioli wrote: > On Wed, Oct 19, 2011 at 9:40 AM, Ian Campbell = wrote: > >> > Guest: > >> > [ =A0 19.607997] ixgbe: Intel(R) 10 Gigabit PCI Express Network Dr= iver - version 3.4.8-k > >> > [ =A0 19.608670] ixgbe: Copyright (c) 1999-2011 Intel Corporation. > >> > [ =A0 19.609465] ixgbe 0000:00:00.0: device not available (can't r= eserve [mem 0xdf300000-0xe32fffff 64bit]) > >> > [ =A0 19.610878] ixgbe: probe of 0000:00:00.0 failed with error -2= 2 > >> > >> Well, that is the problem. > > > > Does he need "e820_host=3D1" in his cfg? > > > Mmm... If you mean putting that line in my DomU config file > (I checked 23428:131f19c67d85, and it seems so), that is not > helping. That option is usually required if the guest has more than 2GB. As we would end up setting an E820 that would trample over the PCI hole. (In this case it looks like part of the PCI hole is DF300000). Dario, I've seen this bug before with .. Hm, some similar adapter. I know that if pass in 'igb.max_vfs=3D2' and passed in the igbvf PCI cards the guest worked just fine. It just did not like being passed in as a real de= vice. Otherwise, older MSI/MSI-X (non SR-IOV) cards worked fine so I never go further in debugging this. I would recommend you take a look at the probe function and figure out wh= y it can't reserve that region. And easy way to figure that out is to boot the guest and look in /proc/iomem and see what is in the df30000-e32= ffffff region. Perhaps something else is overlapping it?