Re: [Qemu-devel] [PATCH] spapr: Fix stale HTAB during live migration

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Samuel Mendoza-Jonas (sam.mj@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.mj@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 / dgilbert@redhat.com / Manchester, UK