[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "'Gordan Bobic'" <gordan@xxxxxxxxxx>
  • From: Jon Skilling <jon_skilling@xxxxxxxxxxx>
  • Date: Tue, 28 May 2013 17:41:40 +0100
  • Cc: xen-users@xxxxxxxxxxxxx
  • Delivery-date: Tue, 28 May 2013 17:16:32 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>
  • Thread-index: AQGCFliQFsDHcj5itccc5WcUoG0moQLncGKFAeoKdJwB1bTsv5l+CYmw

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,


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

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


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.