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

[Xen-devel] swiotlb=force in Konrad's xen-pcifront-0.8.2 pvops domU kernel with PCI passthrough


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Dante Cinco <dantecinco@xxxxxxxxx>
  • Date: Wed, 10 Nov 2010 17:16:14 -0800
  • Delivery-date: Wed, 10 Nov 2010 17:17:03 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=CA18I7sKc1SzbS0cSTuZcG7JlaKc/+MyydtV9PGVZ6u352h73p9FP6DKSOeBL6qF4E tKDpNmeBBCIn9uUSQUO6CvFYfZ3++eaZYbhFZw3pO2vFzfG64LUj8mhzIuMouzNvJsLt b6Y2Lv24eMeDYL/rCwp9iB6P9dlf7kYUafVFA=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

We have Fibre Channel HBA devices that we PCI passthrough to our pvops
domU kernel. Without swiotlb=force in the domU's kernel command line,
both domU and dom0 lock up after loading the kernel module drivers for
the HBA devices. With swiotlb=force, the domU and dom0 are stable
after loading the kernel module drivers but the I/O performance is at
least an order of magnitude worse than what we were seeing with the
HVM kernel. I see the following in /var/log/kern.log in the pvops
domU:

PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
Placing 64MB software IO TLB between ffff880005800000 - ffff880009800000
software IO TLB at phys 0x5800000 - 0x9800000

Is swiotlb=force responsible for the I/O performance degradation? I
don't understand what swiotlb=force does so I would appreciate an
explanation or a pointer.

Thanks.

- Dante

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


 


Rackspace

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