Summary from the previous episodes: ;)
A) Xen 3.1.0 runs fine
B) Any newer version generates SW-IOMMU problem when Dom0 is under I/O
stress.
C) Starting from there, I decided to build a Xen 3.1.3 / Linux 2.6.18.8
kernel excluding all changes related to swiotlb.c.
That means: backout of changsets 15412, 15409, 15408, 15407 and 15405
This configuration runs fine as well!
Then, I re-applied changeset 15405, and the problem re-appears. So the
issue is really linked to this changeset.
Looking at it more in detail, there is only one 'intrusive' change there:
swiotlb.c
575 if (address_needs_mapping(hwdev, dev_addr)) {
becomes
575 if
(range_straddles_page_boundary(page_to_pseudophys(sg->page)
576 + sg->offset, sg->length)
577 || address_needs_mapping(hwdev, dev_addr)) {
And indeed, if I remove the test on 'range_straddles_page_boundary', it
runs fine, if I leave it, I get the SW-IOMMU problem.
To understand how big the impact of the 'range_straddles_page_boundary'
test is, I added an else/printk and it gives:
Apr 21 09:07:45 xenon kernel: SWIOTLB -
range_straddles_page_boundary test bypassed
Apr 21 09:07:58 xenon last message repeated 3629 times
...
so the impact is rather big: about 300 times per second...
This is almost as far as I can go on the topic. My knowledge on what's
really happening in that part of the code is somewhat limited.
So I appreciate any help on how to progress this further.
(Side note: not sure what's happening here, looks like the mailing lists
are broken...)
--
Phil.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home