Xen devel - Mar 2013 - [PATCH] AMD/IOMMU: Process softirqs while building dom0 iommu mappings

Recent changes which have made their way into xen-4.2 stable have pushed the
runtime of construct_dom0() over 5 seconds, which has caused regressions in
XenServer testing because of our 5 second watchdog.

The root cause is that amd_iommu_dom0_init() does not process softirqs and in
particular the nmi_timer which causes the watchdog to decide that no useful
progress is being made.

This patch adds periodic calls to process_pending_softirqs() at the same
interval as the Intel variant of this function.  The server which was failing
with the watchdog test now boots reliably with a timeout of 1 second.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

---
This patch should be backported to Xen-4.2 and 4.1

diff -r a6b81234b189 -r 418b06908cc0 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -317,6 +317,9 @@ static void __init amd_iommu_dom0_init(s
             if ( mfn_valid(pfn) )
                 amd_iommu_map_page(d, pfn, pfn, 
                                    IOMMUF_readable|IOMMUF_writable);
+
+            if ( !(i & 0xfffff) )
+                process_pending_softirqs();
         }
     }

>>> On 18.03.13 at 19:13, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> Recent changes which have made their way into xen-4.2 stable have pushed
the
> runtime of construct_dom0() over 5 seconds, which has caused regressions in
> XenServer testing because of our 5 second watchdog.
The patch looks fine, but can you be a little more precise on which
"recent changes" this is about?

Jan

On 19/03/13 09:36, Jan Beulich wrote:
>>>> On 18.03.13 at 19:13, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
>> Recent changes which have made their way into xen-4.2 stable have
pushed the
>> runtime of construct_dom0() over 5 seconds, which has caused
regressions in
>> XenServer testing because of our 5 second watchdog.
> The patch looks fine, but can you be a little more precise on which
> "recent changes" this is about?
>
> Jan
>
Sadly not specifically - I did a semi-bisect looking at the suspicious
changesets back to the last successful test but have not find an
individual one which makes a significant difference.

As our 4.2 testing is quite new, it is possible it was just a fluke pass
before, meaning the range of "recent changes" might be anything in
4.2.

~Andrew