From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [RFC PATCH 0/2] x86: fix Xen PV regression caused by NUMA page migration Date: Wed, 26 Mar 2014 19:10:23 +0000 Message-ID: <5333261F.8010004@citrix.com> References: <1395425902-29817-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020607060701080201000703" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WStDY-0001lp-IP for xen-devel@lists.xenproject.org; Wed, 26 Mar 2014 19:10:28 +0000 In-Reply-To: <1395425902-29817-1-git-send-email-david.vrabel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: Boris Ostrovsky , xen-devel@lists.xenproject.org, Steven Noonan , Mel Gorman , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --------------020607060701080201000703 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 21/03/14 18:18, David Vrabel wrote: > This series should properly fix the Xen PV guest regression introduced > by 1667918b6483 (mm: numa: clear numa hinting information on > mprotect). The previous fix a9c8e4beeeb6 (xen: properly account for > _PAGE_NUMA during xen pte translations) breaks save/restore > (migration) and needs to be reverted. > > I've only given this series a minimal amount of testing and would > appreciate testing by someone who experienced/reproduced the original > regression. Attached is a simple test program that triggers the bug. Patch #2 fixes the regression and I think that it is the correct fix but I need to confirm it doesn't cause any measurable performance problems on native x86 (I think it should not). I don't have any more time to work on this until next week. David --------------020607060701080201000703 Content-Type: text/x-csrc; name="mprotect.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mprotect.c" #include #include #include #include #define PAGE_SIZE 4096 #define MAGIC 0x79128347ul int main(void) { void *p; volatile unsigned long *m; int ret; /* Map a frame for the test. */ m = p = mmap(NULL, PAGE_SIZE, PROT_WRITE|PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) { perror("mmap"); exit(1); } /* Write to the frame. */ *m = MAGIC; /* Set PROT_NONE on the mapping. */ ret = mprotect(p, PAGE_SIZE, PROT_NONE); if (ret < 0) { perror("mprotect"); exit(1); } /* * Set PROT_READ (or any other non-PROT_NONE protection) on the * mapping. * * On a buggy system pte_mknonnuma() will clear _PAGE_PROTNONE (== * _PAGE_NUMA) and set _PAGE_PRESENT /without/ doing a PFN to MFN * conversion. * * The resulting mapping will be to the wrong MFN. */ ret = mprotect(p, PAGE_SIZE, PROT_READ); if (ret < 0) { perror("mprotect"); exit(1); } /* Check we're still mapping the original frame. */ if (*m != MAGIC) { printf("FAIL (0x%lx != 0x%lx)\n", *m, MAGIC); ret = 1; } /* * On a buggy system, the munmap() will usually trigger a "Bad * page" error since the mapping isn't for the original page. */ munmap(p, PAGE_SIZE); return ret; } --------------020607060701080201000703 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --------------020607060701080201000703--