Re: [Xen-devel] [PATCH PV_OPS] pciback support

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel