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
|
Home