Re: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 8/10/07 17:19, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

> I don't think you're concerned enough about interaction with qemu-dm's
> mapcache. Just because a page that is mapped UC for real hardware
> interaction by a pass-thru domain should not need to be mapped by qemu-dm
> does not mean that either: 1. qemu-dm *already* has it mapped WB in its
> mapcache; or 2. qemu-dm may map it WB in future because the mapcache
> operates at the granularity of multi-page blocks. Also you should be worried
> about Xen's own full 1:1 WB mapping of all RAM (x86/64 Xen only of course).

There is a missing piece here, to fully explain why this is bad: A page
mapped WB permits speculative accesses. Thus data can be pulled into a CPU
cache even though no load/store is ever actually executed on that data. This
is particularly bad if a store operation is speculated -- then the data may
be marked as Modified in the cache (even though it is not actually modified,
just because the speculated operation is a store). Then it gets evicted at
some random point in the future, and written back over whatever critical
command structures happened to be residing there.

Actually it may be the case that if the attribute mismatch involves only
host CPUs then you'll be okay. It depends how much cache consistency is
maintained despite attribute mismatches. All the real-world problems I can
think of involve memory aliasing to multiple physical addresses (e.g., via
GART) and/or interaction with I/O devices. But the PRM does quite strongly
recommend against attribute mismatches.

 -- Keir



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