| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC] x86: cacheability page attributes
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
|
|
|
| |
|
Home