To correctly migrate a PV guest, the toolstack must remove Xen mappings from
the guest pagetables. For 32bit PV guests, the pagetables cannot be walked
from the top so upon encountering an L2 table, the toolstack must decide
whether it contains Xen mappings or not, to avoid corrupting L2s without Xen
mappings.
The migration code performs this search efficiently by knowing that the Xen
mappings will start at a known L2e and point to a known mfn, which will be the
first mfn in the m2p table.
Unfortunately there are two m2p tables in use; the regular and the
compatibility one. The toolstack looks for the first mfn of its own m2p table
in the guest pagetables. This only works if the toolstack is the same bitness
as the 32bit domain being migrated, and leaves a problem for 64bit toolstacks
which will never be able to find its regular m2p in a compat guest.
It appears that this bug for 64bit toolstacks was discovered, but hacked
around in an unsafe manner. The code currently shoots any invalid L2es and
doesn't report a failure for L2 tables in a 32 bit guest, even after the guest
is paused. This means that non Xen entries which should fail the migration
don't, and the guest will resume on the far side with unexpectedly fewer
present pagetable entries.
This patch introduces XENMEM_machphys_compat_mfn_list which permits a 64bit
toolstack to access the compat m2p mfn list, for the purpose of correctly
identifying Xen entries in a 32bit guest.
It is worth noting for completeness that 64bit PV guests don't have any of
these games to play. The Xen mappings are present at a known location in all
L4 tables, so can be safely shot by 32 and 64bit toolstacks without looking at
where the mapping points to.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
projects / xen.git / commit