Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in 3.7-rc1

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Oct 12, 2012 at 07:59:49AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Oct 12, 2012 at 11:28:08AM +0100, Ian Campbell wrote:
> > Hi Konrad,
> > 
> > The following patch causes fairly large packet loss when transmitting
> > from dom0 to the physical network, at least with my tg3 hardware, but I
> > assume it can impact anything which uses this interface.
> 
> Ah, that would explain why one of my machines suddenly started
> developing checksum errors (and had a tg3 card). I hadn't gotten
> deep into it.
> > 
> > I suspect that the issue is that the compound pages allocated in this
> > way are not backed by contiguous mfns and so things fall apart when the
> > driver tries to do DMA.
> 
> So this should also be easily reproduced on barmetal with 'iommu=soft' then.
> > 
> > However I don't understand why the swiotlb is not fixing this up
> > successfully? The tg3 driver seems to use pci_map_single on this data.
> > Any thoughts? Perhaps the swiotlb (either generically or in the Xen
> > backend) doesn't correctly handle compound pages?
> 
> The assumption is that it is just a page. I am surprsed that the other
> IOMMUs aren't hitting this as well - ah, that is b/c they do handle
> a virtual address of more than one PAGE_SIZE..

So.. the GART one (AMD poor man IOTLB - was used for AGP card
translation, but can still be used as an IOMMU - and is still present on
some AMD machines), looks to suffer the same problem.

But perhaps not - can you explain to me if a compound page
is virtually contingous? One of the things the GART does for
pci_map_single is call page_to_phys(p), feeds the CPU physical address
(and size) into the GART engine to setup the mapping.

If compound pages are virtually (and physically on barmetal) contingous
- this ought to work. But if they are not, then this should also break on
AMD machines with tg3 and a AMD GART enabled.

(and I should be able to find such machine in my lab).

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