Re: [Xen-users] Problem with PCI Pass-through address space collision

[Jon Skilling <jon_skilling@xxxxxxxxxxx>]

Hi Gordan,

Sorry about the delay in replying.  It was bank holiday w/end here and I've
been away.  To answer your question, I've already tried building this with
XM instead of XL and it produced the same result.  However, I did have
something of an epiphany whilst I was away and decided to revisit the PCI
specs of the motherboard and PBX card.  The card is a 32bit 33Mhz card which
claims to run correctly in any PCI 2.2 slot or above.  I've already tested
this so I know it's correct.  The slots in the mobo are 64bit, 2 x 133Mhz,1
x 100Mhz, and 1 x 66Mhz and the card was in the 100Mhz slot.
It turns out however, that moving the card to the 66Mhz slot solves the
problem!  It seems a bit silly now that I originally put the card in the
100Mhz slot, but then, it worked fine like that until I introduced xen.
Unfortunately, this wasn't the end of my problems, although it looks like
I'm about 99% there...  For the sake of interest, Asterisk and freePBX seem
to have installed ok, but the dahdi drivers haven't.  This is because I have
to compile the drivers over the xen kernel (3.9.3-1.el6xen.x86_64) and each
of these driver modules displays a warning about "no private gpg key".  It
looks like I may need to patch the install scripts to stop this breaking the
install but this could be the last step before it starts working!

Thanks for your help and suggestions,

Jon

-----Original Message-----
From: Gordan Bobic [mailto:gordan@xxxxxxxxxx] 
Sent: 23 May 2013 07:53
To: Jon Skilling
Cc: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] Problem with PCI Pass-through address space
collision

On 05/21/2013 04:33 PM, Jon Skilling wrote:
> Hi Gordan,
>
> Thanks for your reply.  It is my understanding that PCI pass-through 
> should work for PV guests, which is what I am creating here.  One 
> thing that I notice though, other than XL DMESG giving the message 
> about Vt-d being disabled, is that other than the command line 
> message, iommu=soft doesn't seem to produce any confirmation messages 
> anywhere so I can't really tell if this is running or not.
>
> I have to confess that I have not seen any documentation on XL stating 
> that the device must be detached from Dom0 before it can be attached to a
guest.
> Certainly, XL pci-detach freePBX 06:01.0 produces an error saying that 
> the domain is invalid.  However, I tried your suggestion prior to 
> starting the domain and it runs without complaint and says that the 
> device has been detached.
>
> I reincorporated your suggestion into xen-pciback.conf and added 
> modprobe xen-pciback into rc.local to get everything to start at boot 
> up and restarted the machine.
> I then ran the virsh-nodev-detach command followed by xl create -c 
> freePBX.cfg.  Unfortunately, this produced the same result as before.
>
> I've also tried adding iommu=soft to the Dom0 kernel line, but as I 
> said, this didn't produce any discernible differences to the XL DMESG
output.
>
> Instead of hotplugging, I tried adding the two last lines to the end 
> of the freePBX.cfg file:
>
> name = "freePBX"
> uuid = "91cd5696-1451-c333-f6a4-1628a79976bd"
> maxmem = 1024
> memory = 1024
> vcpus = 1
> bootloader = "pygrub"
> localtime = 0
> on_poweroff = "destroy"
> on_reboot = "restart"
> on_crash = "restart"
> disk = [ "phy:/dev/VolGroup/freePBX,xvda,w" ] vif = [ 
> "mac=00:16:3e:00:9a:9c,bridge=br0,script=vif-bridge,vifname=vif2.0"
> ]
>
> extra = "iommu=soft debug loglevel=10 earlyprintk=xenboot console=hvc0 
> ro xencons=tty"
> pci = ['06:01.0,permissive=1']
>
> As you can see from above, I'm allocating 1024Mb to the guest.  I 
> haven't got time now until the weekend to apply the 4.2.2-5 patches to 
> check if they solve my problem, but I'll post a message when I've done 
> it to update on how it went.  Suffice to say, I'm still getting the 
> same error message :-(

Have you tried using xm instead of xl? I'm finding that xl is still missing
some vital features to make everything work.

I'd also start with getting a standard HVM domU working with xm and then
take it further from there.

I'm pretty sure iommu=soft shouldn't be on the domU kernel boot parameters.
I suggest you start by removing the extra= line and remove the ,permissive=1
from the pci spec since I don't think xm understands that (you have it in
your module config anyway). Then see if you can get it working with xm/xend
as a HVM.

Gordan


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users