From: David Vrabel <david.vrabel@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
xen-devel@lists.xenproject.org,
Steven Noonan <steven@uplinklabs.net>,
Mel Gorman <mgorman@suse.de>,
Elena Ufimtseva <ufimtseva@gmail.com>
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 [thread overview]
Message-ID: <5333261F.8010004@citrix.com> (raw)
In-Reply-To: <1395425902-29817-1-git-send-email-david.vrabel@citrix.com>
[-- Attachment #1: Type: text/plain, Size: 815 bytes --]
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
[-- Attachment #2: mprotect.c --]
[-- Type: text/x-csrc, Size: 1407 bytes --]
#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#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;
}
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-03-26 19:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 18:18 [RFC PATCH 0/2] x86: fix Xen PV regression caused by NUMA page migration David Vrabel
2014-03-21 18:18 ` [PATCH 1/2] Revert "xen: properly account for _PAGE_NUMA during xen pte translations" David Vrabel
2014-03-21 18:18 ` [PATCH 2/2] x86: use pv-ops in {pte, pmd}_{set, clear}_flags() David Vrabel
2014-03-24 11:28 ` David Vrabel
[not found] ` <CAKbGBLiVqaHEOZx6y4MW4xDTUdKRhVLZXTTGiqYT7vuH2Wgeww@mail.gmail.com>
2014-03-25 20:16 ` [PATCH 2/2] x86: use pv-ops in {pte,pmd}_{set,clear}_flags() Linus Torvalds
2014-03-31 12:26 ` Mel Gorman
2014-03-31 15:41 ` Linus Torvalds
2014-03-31 16:10 ` Linus Torvalds
2014-03-31 16:27 ` Cyrill Gorcunov
2014-04-01 18:18 ` David Vrabel
2014-04-01 18:43 ` Linus Torvalds
2014-04-01 19:03 ` Cyrill Gorcunov
2014-04-02 11:33 ` Pavel Emelyanov
2014-04-02 13:29 ` Cyrill Gorcunov
2014-03-26 19:10 ` David Vrabel [this message]
2014-04-15 8:24 ` [RFC PATCH 0/2] x86: fix Xen PV regression caused by NUMA page migration David Sutton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5333261F.8010004@citrix.com \
--to=david.vrabel@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=mgorman@suse.de \
--cc=steven@uplinklabs.net \
--cc=ufimtseva@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.