[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use

On 22.08.2013 09:54, Jan Beulich wrote:
>>>> On 21.08.13 at 19:28, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> On Wed, Aug 21, 2013 at 6:48 AM, David Vrabel <david.vrabel@xxxxxxxxxx> 
>> 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.

> 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

Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.