WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Su, Disheng" <disheng.su@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 08 Oct 2007 17:40:09 +0100
Delivery-date: Mon, 08 Oct 2007 09:35:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C330171F.E915%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgJfbiHYf5t3raCT5qrRGbrSVAc4gAAyqLhAAJeet0ADAbXoAAB7d2HAAAMIeAAASe6pQAAuRPn
Thread-topic: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
User-agent: Microsoft-Entourage/11.3.6.070618
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