|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH PV_OPS] pciback support
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, >> > 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= and reassign_resources to make things >> 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 device > not work? > Can you attach the output of 'lspci -vvv' with and without the "guestdev=.. > 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 thing > as the the 'pciback.hide=' argument? The extra functionality is with the > 'reassign_resources' which does two major things: > 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 bus > addresses? > Presumarily the guest OS? > 2) in pci_assign_resources, pbus_size_mem, and in pdev_sort_resources aligns > 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 checks > whether > it was page-aligned. > So, I was wondering whether both of these things were neccessary in the Xen > 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 map > page-aligned > addresses to the MMIO for the guest? I thought I saw a patch couple of days > that > just did that... > Any response would be appreciated - I was thinking to see how Sander fares > and if > it fails for him, look at xm/xc and qemu to see if something can be done > there. >> >> Are these also ported/available on the 2.6.31.1/pv_ops kernel or not needed >> anymore ? >> >> Complete lines in grub dom0: >> >> kernel /xen-3.4.1.gz dom0_mem=768M xencons=hvc >> module /vmlinuz-2.6.29.6 root=/dev/mapper/serveerstertje-root ro >> pci=nomsi >> pciback.hide=(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=00: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=256,force console=tty0 >> module /initrd.img-2.6.29.6 >> >> 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 >> >> >> Regards, >> >> Sander Eikelenboom >> >> >> >> >> Tuesday, October 13, 2009, 11:22:19 PM, you wrote: >> >> > 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 space and >> > to have the BARs mapped properly for the guest. >> >> > 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 >> >> > and add this entry: >> >> > pci = [ '0000:01.14.0' ] >> >> > in your .xm file. >> >> > The PV guest, if it has the PCI frontend, should now see the PCI device. >> > I've tested this succesfully with a SLES10 PV guest with a couple of >> > devices. >> >> > 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. >> >> > On my machine it lead to Dom0 deciding that a spurrious interrupt kicked >> > 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 line is >> > being shared beforehand by xm?, or do something in Xen?). >> >> >> >> >> >> >> >> -- >> Best regards, >> Sander mailto:linux@xxxxxxxxxxxxxx >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel -- Best regards, Sander mailto:linux@xxxxxxxxxxxxxx _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |