From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org
Subject: Re: Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use
Date: Thu, 22 Aug 2013 11:06:38 +0200 [thread overview]
Message-ID: <5215D49E.6000501@canonical.com> (raw)
In-Reply-To: <5215DFE302000078000ED8C6@nat28.tlf.novell.com>
[-- Attachment #1.1: Type: text/plain, Size: 2381 bytes --]
On 22.08.2013 09:54, Jan Beulich wrote:
>>>> On 21.08.13 at 19:28, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Wed, Aug 21, 2013 at 6:48 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>>> All,
>>>
>>> 179ef71c (mm: save soft-dirty bits on swapped pages) introduces a new
>>> PTE bit on x86 _PTE_SWP_SOFT_DIRTY which has the same value as _PTE_PSE
>>> and _PTE_PAT.
>>>
>>> With a Xen PV guest, the use of the _PTE_PAT will result in the page
>>> having unexpected cachability which will introduce a range of subtle
>>> performance and correctness issues. Xen programs the entry 4 in the PAT
>>> table with WC so a page that was previously WB will end up as WC.
>>>
>>
>> Kind of off topic, but do you have a summary of how Xen uses the high
>> PAT bits? I'm the one who wants WT, and if there's already precedent
>> for using the high PAT bits, it'll be helpful.
>
> Xen's public headers have a comment explaining this, with the
> main information being this table:
>
> * The PAT MSR is as follow (it is a 64-bit value, each entry is 8 bits):
> * PAT4 PAT0
> * +---+----+----+----+-----+----+----+
> * WC | WC | WB | UC | UC- | WC | WB | <= Linux
> * +---+----+----+----+-----+----+----+
> * WC | WT | WB | UC | UC- | WT | WB | <= BIOS (default when machine boots)
> * +---+----+----+----+-----+----+----+
> * WC | WP | WC | UC | UC- | WT | WB | <= Xen
> * +---+----+----+----+-----+----+----+
That looks odd and I think the kernel arch/x86/xen/mmu.c has a more correct
summary. As much as I remember the specs and the usage in Linux, the upper
four slots are mirroring the lower 4 ones. That way PTEs don't need to care to
what value the PAT bit is set. The BIOS default would result in the same meaning
of PCD and PWT as without PAT. Linux changes it to get WC but otherwise
continues to avoid the PAT bit which moves position for large pages.
-Stefan
>
> i.e. Xen is retaining the BIOS (and legacy from non-PAT times)
> meaning of the low four entries, putting WC and WP up into
> the high half. The fact that the entry 6 is defined to be WC
> is perhaps a mistake - it should really be considered reserved
> for an eventual future memory type (just like entry 7). It also
> seems like entry 6 is documented incorrectly here for Linux and
> BIOS.
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
[-- Attachment #2: 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:[~2013-08-22 9:06 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 13:48 Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use David Vrabel
2013-08-21 13:53 ` konrad wilk
2013-08-21 13:53 ` konrad wilk
2013-08-21 14:11 ` H. Peter Anvin
2013-08-21 14:19 ` Cyrill Gorcunov
2013-08-21 14:19 ` Cyrill Gorcunov
2013-08-21 14:22 ` H. Peter Anvin
2013-08-21 14:22 ` H. Peter Anvin
2013-08-21 14:29 ` Cyrill Gorcunov
2013-08-21 14:29 ` Cyrill Gorcunov
2013-08-21 16:30 ` Linus Torvalds
2013-08-21 16:42 ` Cyrill Gorcunov
2013-08-21 16:42 ` Cyrill Gorcunov
2013-08-21 23:05 ` Cyrill Gorcunov
2013-08-21 23:05 ` Cyrill Gorcunov
2013-08-21 23:42 ` Andi Kleen
2013-08-22 5:49 ` Cyrill Gorcunov
2013-08-22 5:49 ` Cyrill Gorcunov
2013-08-22 6:37 ` Minchan Kim
2013-08-22 6:37 ` Minchan Kim
2013-08-22 13:12 ` Cyrill Gorcunov
2013-08-22 13:12 ` Cyrill Gorcunov
2013-08-21 23:42 ` Andi Kleen
2013-08-27 22:04 ` Benjamin Herrenschmidt
2013-08-27 22:04 ` Benjamin Herrenschmidt
2013-08-21 16:30 ` Linus Torvalds
2013-08-21 14:11 ` H. Peter Anvin
2013-08-21 14:12 ` Cyrill Gorcunov
2013-08-21 14:22 ` H. Peter Anvin
2013-08-21 14:22 ` H. Peter Anvin
2013-08-21 14:53 ` Jan Beulich
2013-08-21 14:53 ` Jan Beulich
2013-08-21 14:58 ` H. Peter Anvin
2013-08-21 14:58 ` H. Peter Anvin
2013-08-21 15:42 ` Cyrill Gorcunov
2013-08-21 16:03 ` Jan Beulich
2013-08-21 16:19 ` Cyrill Gorcunov
2013-08-21 16:56 ` David Vrabel
2013-08-21 16:56 ` David Vrabel
2013-08-21 17:25 ` Cyrill Gorcunov
2013-08-21 17:25 ` Cyrill Gorcunov
2013-08-21 18:17 ` Cyrill Gorcunov
2013-08-21 18:50 ` H. Peter Anvin
2013-08-21 19:03 ` Cyrill Gorcunov
2013-08-21 19:07 ` Andy Lutomirski
2013-08-21 19:07 ` Andy Lutomirski
2013-08-21 19:20 ` Cyrill Gorcunov
2013-08-21 19:20 ` Cyrill Gorcunov
2013-08-21 19:21 ` Pavel Emelyanov
2013-08-21 19:21 ` Pavel Emelyanov
2013-08-21 23:04 ` Linus Torvalds
2013-08-22 0:51 ` Dave Jones
2013-08-22 5:44 ` Cyrill Gorcunov
2013-08-22 5:44 ` Cyrill Gorcunov
2013-08-22 6:41 ` Pavel Emelyanov
2013-08-22 6:41 ` Pavel Emelyanov
2013-08-22 0:51 ` Dave Jones
2013-08-22 7:47 ` Jan Beulich
2013-08-22 7:47 ` Jan Beulich
2013-08-22 9:32 ` David Vrabel
2013-08-22 10:16 ` Pavel Emelyanov
2013-08-22 10:16 ` Pavel Emelyanov
2013-08-22 9:32 ` David Vrabel
2013-08-21 23:04 ` Linus Torvalds
2013-08-21 19:03 ` Cyrill Gorcunov
2013-08-21 18:50 ` H. Peter Anvin
2013-08-21 18:17 ` Cyrill Gorcunov
2013-08-22 6:56 ` Jan Beulich
2013-08-22 7:03 ` Cyrill Gorcunov
2013-08-22 7:03 ` Cyrill Gorcunov
2013-08-22 7:27 ` Jan Beulich
2013-08-22 11:27 ` Cyrill Gorcunov
2013-08-22 11:33 ` Jan Beulich
2013-08-22 12:18 ` Pavel Emelyanov
2013-08-22 12:18 ` Pavel Emelyanov
2013-08-22 11:33 ` Jan Beulich
2013-08-22 11:27 ` Cyrill Gorcunov
2013-08-22 7:27 ` Jan Beulich
2013-08-22 6:56 ` Jan Beulich
2013-08-21 16:19 ` Cyrill Gorcunov
2013-08-21 16:03 ` Jan Beulich
2013-08-21 15:42 ` Cyrill Gorcunov
2013-08-21 14:12 ` Cyrill Gorcunov
2013-08-21 17:28 ` Andy Lutomirski
2013-08-21 17:28 ` Andy Lutomirski
2013-08-22 7:54 ` Jan Beulich
2013-08-22 7:54 ` Jan Beulich
2013-08-22 9:06 ` Stefan Bader [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-08-21 13:48 David Vrabel
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=5215D49E.6000501@canonical.com \
--to=stefan.bader@canonical.com \
--cc=xen-devel@lists.xen.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.