[PATCH v2] dom0/pvh: fix processing softirqs during memory map population

[PATCH v2] dom0/pvh: fix processing softirqs during memory map population

[Roger Pau Monne]

Make sure softirqs are processed after every successful call to
guest_physmap_add_page. Even if only a single page is to be added,
it's unknown whether the p2m or the IOMMU will require splitting the
provided page into smaller ones, and thus in case of having to break
a 1G page into 4K entries the amount of time taken by a single of
those additions will be non-trivial. Stay on the safe side an check
for pending softirqs on ever successful loop iteration.

Fixes: 5427134eae ('x86: populate PVHv2 Dom0 physical memory map')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Unconditionally process softirqs after every successful loop
   iteration.
---
 xen/arch/x86/hvm/dom0_build.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 549ff8ec7c..cbc28113cb 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -114,10 +114,9 @@ static int __init pvh_populate_memory_range(struct domain *d,
         { .align = PFN_DOWN(MB(2)), .order = PAGE_ORDER_2M },
         { .align = PFN_DOWN(KB(4)), .order = PAGE_ORDER_4K },
     };
-    unsigned int max_order = MAX_ORDER, i = 0;
+    unsigned int max_order = MAX_ORDER;
     struct page_info *page;
     int rc;
-#define MAP_MAX_ITER 64
 
     while ( nr_pages != 0 )
     {
@@ -186,12 +185,16 @@ static int __init pvh_populate_memory_range(struct domain *d,
         start += 1UL << order;
         nr_pages -= 1UL << order;
         order_stats[order]++;
-        if ( (++i % MAP_MAX_ITER) == 0 )
-            process_pending_softirqs();
+        /*
+         * Process pending softirqs on every successful loop: it's unknown
+         * whether the p2m/IOMMU code will have split the page into multiple
+         * smaller entries, and thus the time consumed would be much higher
+         * than populating a single entry.
+         */
+        process_pending_softirqs();
     }
 
     return 0;
-#undef MAP_MAX_ITER
 }
 
 /* Steal RAM from the end of a memory region. */
-- 
2.34.1

Re: [PATCH v2] dom0/pvh: fix processing softirqs during memory map population

[Jan Beulich]

On 07.02.2022 12:20, Roger Pau Monne wrote:
> Make sure softirqs are processed after every successful call to
> guest_physmap_add_page. Even if only a single page is to be added,
> it's unknown whether the p2m or the IOMMU will require splitting the
> provided page into smaller ones, and thus in case of having to break
> a 1G page into 4K entries the amount of time taken by a single of
> those additions will be non-trivial. Stay on the safe side an check
> for pending softirqs on ever successful loop iteration.
> 
> Fixes: 5427134eae ('x86: populate PVHv2 Dom0 physical memory map')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

Nit: I guess it's "and" and "every" in the last sentence. I'd be
happy to adjust while committing.

Jan

Re: [PATCH v2] dom0/pvh: fix processing softirqs during memory map population

[Roger Pau Monné]

On Mon, Feb 07, 2022 at 01:41:38PM +0100, Jan Beulich wrote:
> On 07.02.2022 12:20, Roger Pau Monne wrote:
> > Make sure softirqs are processed after every successful call to
> > guest_physmap_add_page. Even if only a single page is to be added,
> > it's unknown whether the p2m or the IOMMU will require splitting the
> > provided page into smaller ones, and thus in case of having to break
> > a 1G page into 4K entries the amount of time taken by a single of
> > those additions will be non-trivial. Stay on the safe side an check
> > for pending softirqs on ever successful loop iteration.
> > 
> > Fixes: 5427134eae ('x86: populate PVHv2 Dom0 physical memory map')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> 
> Nit: I guess it's "and" and "every" in the last sentence. I'd be
> happy to adjust while committing.

Yes please, if you are happy to adjust on commit.

Thanks, Roger.