Re: [PATCH v4 11/16] PoC: libs/guest: use foreign copy during migration

[Frediano Ziglio <freddy77@xxxxxxxxx>]

On Wed, 3 Jun 2026 at 15:09, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 03/06/2026 2:05 pm, Frediano Ziglio wrote:
> > From: Edwin Török <edwin.torok@xxxxxxxxxx>
> >
> > ministat confirms the improvement:
> >
> > ```
> > x baseline
> > + foreigncopy
> >     N           Min           Max        Median           Avg        Stddev
> > x  20     1.1306997     1.1447931     1.1356569     1.1365742   0.003242175
> > +  20     0.4311504    0.44180303    0.43616705    0.43600089  0.0031094689
> > Difference at 95.0% confidence
> >       -0.700573 +/- 0.00203311
> >       -61.639% +/- 0.133355%
> >       (Student's t, pooled s = 0.00317652)
> > ```
> >
> > The tests pass too, which means that it has correctly migrated all guest
> > memory.
> >
> > Frediano: This PoC was adapted to be included in a final series.
> >
> > Signed-off-by: Edwin Török <edwin.torok@xxxxxxxxxx>
> > Signed-off-by: Frediano Ziglio <frediano.ziglio@xxxxxxxxxx>
>
> This patch is definitely out of order, seeing as you don't introduce the
> new hypercall until the following patch.
>

Yes and no. In the original PoC it was, as it was trying to check
performance difference using the new hypercall. But to prove that code
was working the new hypercalls were "emulated" using functions doing
map/copy/unmap. This also makes sure no performance regressions using
the new wrappers. So the code works with or without the new
hypercalls.

> But there's also absolutely no information what those stats are.  From
> memory, I think it was wallclock time of migrating a VM, but there are
> no units or sizes of the VM presented, so those are just random numbers.
>

I had the same though. I quickly searched if Edwin reappeared on ML
but it seems not at the moment.

> It also doesn't state whether it's measured from a PV or a PVH guest.
> However bad PV is (and it is bad), I think the improvement will be
> better in a PVH guest, because the foreign map/unmap operations being
> replaced are even more expensive in PVH.
>

The PoC was simply stripping out PV support so surely they were
PVH/HVM statistics.

> There's another area in libxenguest which would likely benefit; domain
> construction.  Even with kernels and initrds in the MB range, foreign
> copy is probalby a win, and it surely will be for e.g. the ACPI tables
> which are a few kB.
>
> ~Andrew

Frediano