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