From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8644EC433E2 for ; Fri, 11 Sep 2020 11:56:16 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 32219221E7 for ; Fri, 11 Sep 2020 11:56:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="ej08xkoX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32219221E7 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kGher-0001l9-HJ; Fri, 11 Sep 2020 11:56:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kGheq-0001l3-SH for xen-devel@lists.xenproject.org; Fri, 11 Sep 2020 11:56:00 +0000 X-Inumbo-ID: b7651257-cf97-4412-a118-fcd441b99a49 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7651257-cf97-4412-a118-fcd441b99a49; Fri, 11 Sep 2020 11:55:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1599825359; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ddJSaeXvV8HHijui8S3vmZPwvxFvseGTCx6ZahYtTOk=; b=ej08xkoXN2MaI+qpL9ZejjsnTf32tw5HQ1Z7yyw3FtF+ysrNUnCJnXno uvPrmE7FJJcImawmDn2Fl7pNk4oIqhHn5u31Yq8rreY2W1PKER7jmNtxt bgEnvhGqCYbHijwO/rzhhP+9/xJVZkiOkPNXQg1bQJaMSEMVlilj4qyuX Y=; Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zGttxFN85QYmhvx0oKv9pmNbXPpyW5Os7A42972woer+pXXByQr1XUTrB3eddolxMPp8fKfZT3 bmsSycJGvMmT8cWE/pMagmd+vQMyNAilvxe6dLqHnJaHnGVsE65vjBmUn8lnMt0qcCU9T5WfhK SDpJfqyePsoQbZJYPnIyaU8ntpD9m4NU8pMQBaWCPtHZd93RP97gd4KEL0Xa6WtDEL1YVgYB3/ 6xPTDsjpFolouN9YM7icm9tUdEAzs0JisKRiYMn7PpHRxOWkoFUYqt01ePcowbCIT7p/taFT6g sj8= X-SBRS: 2.7 X-MesageID: 26786440 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.76,415,1592884800"; d="scan'208";a="26786440" Subject: Re: [PATCH] x86/PV: make post-migration page state consistent To: Jan Beulich , "xen-devel@lists.xenproject.org" CC: Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: From: Andrew Cooper Message-ID: <2e715145-e0b5-07b9-0090-6e1e9a849f33@citrix.com> Date: Fri, 11 Sep 2020 12:55:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To FTLPEX02CL05.citrite.net (10.13.108.178) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11/09/2020 11:34, Jan Beulich wrote: > When a page table page gets de-validated, its type reference count drops > to zero (and PGT_validated gets cleared), but its type remains intact. > XEN_DOMCTL_getpageframeinfo3, therefore, so far reported prior usage for > such pages. An intermediate write to such a page via e.g. > MMU_NORMAL_PT_UPDATE, however, would transition the page's type to > PGT_writable_page, thus altering what XEN_DOMCTL_getpageframeinfo3 would > return. In libxc the decision which pages to normalize / localize > depends solely on the type returned from the domctl. As a result without > further precautions the guest won't be able to tell whether such a page > has had its (apparent) PTE entries transitioned to the new MFNs. I'm afraid I don't follow what the problem is. Yes - unvalidated pages probably ought to be consistently NOTAB, so this is probably a good change, but I don't see how it impacts the migration logic. We already have to cope with a page really changing types in parallel with the normalise/localise logic (that was a "fun" one to debug), which is why errors in that logic are specifically not fatal while the guest is live - the frame gets re-marked as dirty, and deferred until the next round. Errors encountered after the VM has been paused are fatal. However, at no point, even with an unvalidated pagetable type, can the contents of the page be anything other than legal PTEs.  (I think) ~Andrew