Re: [Xen-devel] [RFC] x86: cacheability page attributes

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 3/4/07 15:00, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Attached draft patch is supposed to help dealing with tracking cacheability
> attributes on x86, specifically to prevent page aliases using different
> cacheability attributes.

How important is this to get right? The Intel manual warns a bit vaguely
about it, but I get the impression that nothing actually breaks in terms of
cache coherency if a page is mapped with more than one PAT attribute (very
much unlike the situation if CPUs have differing MTRR attributes!). The
manual explains that even if a UC attribute is chosen, for example, the
processor's cache will continue to snoop for accesses/updates of that line.

This is something I'd be very interested to get a definitive answer on from
Intel and AMD.

 -- Keir

> The problem with the approach of extending the
> set of page types (by splitting PGT_writable_page) is that a simple update
> of a pte which changes nothing but _PAGE_PWT or _PAGE_PCD doesn't
> work, as the scheme requires the old type (e.g. simple writeable page) to
> first drop its type reference count to zero, before the new type can be
> established.
> 
> While in all previous scenarios this doesn't present a problem, here it simply
> seems wrong: If the only use is through the pte being updated, this one
> reference shouldn't be considered. As I understand it, racing requests to
> bump the type reference count could be avoided by clearing PGT_validated
> while retaining the single reference, but what I don't have a reasonable
> idea for is how (and where) to handle the transition while retaining the
> type reference.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel