From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm8eH-0008Hj-IW for qemu-devel@nongnu.org; Wed, 05 Nov 2014 17:02:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xm8e3-0002IL-QI for qemu-devel@nongnu.org; Wed, 05 Nov 2014 17:01:53 -0500 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:38139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xm8e3-0002FL-71 for qemu-devel@nongnu.org; Wed, 05 Nov 2014 17:01:39 -0500 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 6 Nov 2014 08:01:35 +1000 Message-ID: <545A9E13.2000804@au1.ibm.com> Date: Thu, 06 Nov 2014 09:00:51 +1100 From: Samuel Mendoza-Jonas MIME-Version: 1.0 References: <1415168221-2324-1-git-send-email-sam.mj@au1.ibm.com> <1415168221-2324-3-git-send-email-sam.mj@au1.ibm.com> <5459DA66.6070602@suse.de> In-Reply-To: <5459DA66.6070602@suse.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 2/2] spapr: Fix stale HTAB during live migration (TCG) Reply-To: sam.mj@au1.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 05/11/14 19:05, Alexander Graf wrote: > > > On 05.11.14 07:17, Samuel Mendoza-Jonas wrote: >> If a TCG guest reboots during a running migration HTAB entries are not >> marked dirty, and the destination boots with an invalid HTAB. >> >> When a reboot occurs reset the state of HTAB migration, and explicitly >> inform the destination of invalid entries. >> >> Signed-off-by: Samuel Mendoza-Jonas >> --- >> hw/ppc/spapr.c | 59 +++++++++++++++++++++++++++++++++++--------------- >> include/hw/ppc/spapr.h | 1 + >> 2 files changed, 42 insertions(+), 18 deletions(-) >> >> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c >> index 1610c28..9f419e8 100644 >> --- a/hw/ppc/spapr.c >> +++ b/hw/ppc/spapr.c >> @@ -829,26 +829,30 @@ static void spapr_reset_htab(sPAPREnvironment *spapr) >> >> shift = kvmppc_reset_htab(spapr->htab_shift); >> >> + pthread_mutex_lock(&spapr->htab_mutex); >> if (shift > 0) { >> /* Kernel handles htab, we don't need to allocate one */ >> spapr->htab_shift = shift; >> kvmppc_kern_htab = true; >> >> /* Tell readers to update their file descriptor */ >> - pthread_mutex_lock(&spapr->htab_mutex); >> if (spapr->htab_fd > 0) { >> spapr->htab_fd_stale = true; >> } >> - pthread_mutex_unlock(&spapr->htab_mutex); >> } else { >> if (!spapr->htab) { >> /* Allocate an htab if we don't yet have one */ >> spapr->htab = qemu_memalign(HTAB_SIZE(spapr), HTAB_SIZE(spapr)); >> + } else { >> + spapr->htab_mig_full = true; >> + spapr->htab_first_pass = true; >> + spapr->htab_save_index = 0; > > You could just set the dirty bitmap to "all dirty" here, no? Then you > don't need all the changes belong I presume? Yes, then you just need to reset htab_save_index to zero. The idea of this approach was to avoid walking the HTAB twice (once to dirty and once to read it). But it is a lot of changes for a fairly small benefit. If setting it dirty is preferred I'll test and send that version. Thanks! > >> } >> >> /* And clear it */ >> memset(spapr->htab, 0, HTAB_SIZE(spapr)); > > ... so instead of memset(0)ing it, you could just > > ppc_hash64_store_hpte(env, i, HPTE64_V_HPTE_DIRTY, 0); > > the HTAB in a loop. > > > Alex > -- ----------- LTC Ozlabs IBM