From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: [PATCH PV_OPS] pciback support Date: Thu, 15 Oct 2009 21:49:13 +0200 Message-ID: <265882812.20091015214913@eikelenboom.it> References: <1255468952-27052-1-git-send-email-konrad.wilk@oracle.com> <1407611321.20091014211953@eikelenboom.it> <20091015183835.GA11348@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20091015183835.GA11348@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: shimada-yxb@necst.nec.co.jp, Jeremy Fitzhardinge , xen-devel@lists.xensource.com, barak@neocleus.com, jbarnes@virtuousgeek.org, u.zhao@intel.com List-Id: xen-devel@lists.xenproject.org Hello Konrad, hmmm that was some time ago when i figured this one out :-) But i think i will have some time tomorrow to boot without on the 2.6.29.6 = kernel and see what is does ... For what i remember it was especially necessary for the USB cards to work, = the internal sound card worked ok without. Regards, Sander Thursday, October 15, 2009, 8:38:35 PM, you wrote: > On Wed, Oct 14, 2009 at 09:19:53PM +0200, Sander Eikelenboom wrote: >> Hello Konrad, >>=20 > Hey Sander, >> With the 2.6.18.8 kernel and 2.6.29.6 port of the xen kernel (on xen 3.4= .1 hypervisor) >> I had to use an additional guestdev=3D and reassign_resources to make th= ings work. > I digged a bit more in this. What was the result of not passing those > arguments? Did the kernel notice a spurious interrupt? Or would the devic= e not work? > Can you attach the output of 'lspci -vvv' with and without the "guestdev= =3D.. reassign_resources" > parameters with your 2.6.18.8 (or 2.6.29.6 port) kernel. > Yuji, Yu, Jesse, and Barak: > The 'guestdev.c' and its parameter 'guestdev' look to be doing the same t= hing > as the the 'pciback.hide=3D' argument? The extra functionality is with the > 'reassign_resources' which does two major things:=20 > 1) in quirk_release_resources disables the PCI card from latching on the > bus addresses that fall within its BARs - which is done during the > chain of invocations when 'pci_enable_device' was called. > Thought I am curious - who then re-enables the card to latch on the b= us addresses? > Presumarily the guest OS? > 2) in pci_assign_resources, pbus_size_mem, and in pdev_sort_resources al= igns > the BARs to page size. Past checkins in the 2.6.18.hg suggest this is= b/c in the past > mmio resources were translated from PFNs->MFNs and there were no chec= ks whether > it was page-aligned. > So, I was wondering whether both of these things were neccessary in the X= en 3.5 and PV-OPS kernel? > Is the mapping of the MMIO resources done b/c xm/xc/qemu can't deal with = resources > which are not page-aligned? Would it not be easier to fix xm/xc/qemu to m= ap page-aligned > addresses to the MMIO for the guest? I thought I saw a patch couple of da= ys that > just did that... > Any response would be appreciated - I was thinking to see how Sander fare= s and if > it fails for him, look at xm/xc and qemu to see if something can be done = there. >>=20 >> Are these also ported/available on the 2.6.31.1/pv_ops kernel or not nee= ded anymore ? >>=20 >> Complete lines in grub dom0: >>=20 >> kernel /xen-3.4.1.gz dom0_mem=3D768M xencons=3Dhvc >> module /vmlinuz-2.6.29.6 root=3D/dev/mapper/serveerstertje-root= ro pci=3Dnomsi pciback.hide=3D(00:07.0)(06:01.0)(06:01.1)(06:01.2)(01:08.0= )(01:08.1)(01:08.2)(01:0a.0) guestdev=3D00:07.0,06:01.0,06:01.1,06:01.2,01= :08.0,01:08.1,01:08.2,01:0a.0 reassign_resources swiotlb=3D256,force consol= e=3Dtty0 >> module /initrd.img-2.6.29.6 >>=20 >> making this work for me by passing through 2 USB cards (one pci one pci-= e) and a integrated intel hda sound card) to domU's >>=20 >>=20 >> Regards, >>=20 >> Sander Eikelenboom >>=20 >>=20 >>=20 >>=20 >> Tuesday, October 13, 2009, 11:22:19 PM, you wrote: >>=20 >> > This is back-port (up-port?) of the pci-back driver from the 2.6.18.hg= tree. >> > The driver is quite similar to the pci-stub, excep that is intended for >> > paravirtualized guests. This driver works in conjunction with the pci-= front >> > (frontend driver) to exchange PCI write/read to the configuration spac= e and >> > to have the BARs mapped properly for the guest. >>=20 >> > The usage of this is, as said, is similar to pci-stub: >> > lspci | grep SCSI >> > 01:14.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U >> > echo "0000:01:14.0" > /sys/bus/pci/drivers/aic94xx/unbind >> > echo "0000:01:14.0" > /sys/bus/pci/drivers/pciback/new-slot >> > echo "0000:01:14.0" > /sys/bus/pci/drivers/aic94xx/bind >>=20 >> > and add this entry: >>=20 >> > pci =3D [ '0000:01.14.0' ] >>=20 >> > in your .xm file. >>=20 >> > The PV guest, if it has the PCI frontend, should now see the PCI devic= e. >> > I've tested this succesfully with a SLES10 PV guest with a couple of d= evices. >>=20 >> > But please be beware of this warning if it shows up: >> > (XEN) irq.c:1113:d1 Cannot bind IRQ 17 to guest. Others do not share. >>=20 >> > On my machine it lead to Dom0 deciding that a spurrious interrupt kick= ed off >> > and it disabled the IRQ. The end result was that other devices on the = same >> > interrupt line stopped working. I am not yet certain how to make this = work >> > properly (whether to check if the PCI device in question interrupt lin= e is >> > being shared beforehand by xm?, or do something in Xen?). >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> Best regards, >> Sander mailto:linux@eikelenboom.it >>=20 >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel --=20 Best regards, Sander mailto:linux@eikelenboom.it