* Samuel Mendoza-Jonas (sam...@au1.ibm.com) wrote:
> If a guest reboots during a running migration, changes to the
> hash page table are not necessarily updated on the destination.
> Opening a new file descriptor to the HTAB forces the migration
> handler to resend the entire table.
>
> Signed-off-by: Samuel Mendoza-Jonas <sam...@au1.ibm.com>
> ---
> hw/ppc/spapr.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 3a6d26d..7733b37 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -997,6 +997,12 @@ static void spapr_reset_htab(sPAPREnvironment *spapr)
> /* Kernel handles htab, we don't need to allocate one */
> spapr->htab_shift = shift;
> kvmppc_kern_htab = true;
> +
> + /* Make sure readers are aware of the reset */
> + if (spapr->htab_fd > 0) {
> + close(spapr->htab_fd);
> + spapr->htab_fd = kvmppc_get_htab_fd(false);
> + }
If this function can be called during migration, then
if we're unlucky can't that happen during a call to htab_save_iterate
from the migration thread?
If so what would happen if that htab_save_iterate call was made
just between the close() and the reopen?
Dave
> } else {
> if (!spapr->htab) {
> /* Allocate an htab if we don't yet have one */
> --
> 1.9.3
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
