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:19:27 +0100
Delivery-date: Mon, 08 Oct 2007 09:15:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <391BF3CDD2DC0848B40ACB72FA97AD59023A9E61@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AcgJfbiHYf5t3raCT5qrRGbrSVAc4gAAyqLhAAJeet0ADAbXoAAB7d2HAAAMIeAAASe6pQ==
Thread-topic: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
User-agent: Microsoft-Entourage/11.3.6.070618
On 8/10/07 17:00, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:

>> Won't WBINVD and CLFLUSH also need to be virtualised?
> Why? Can you give me more hints? If guest try to flush cache, just let
> it do it, right?

If a VCPU is migrated across physical CPUs, it can leave multiple dirty
caches in its wake.

> And yes, this patch is mainly for pass-thru domains. But for
> non-pass-thru domain, I think some work may still needed. For example,
> currently we always set _PAGE_PAT/_PAGE_PCD/_PAGE_PWT to be 0, and the
> real meaning of this combination depends on host PAT MTRR setting, and
> not always WB.
> Of course, that may be simpler.

The host PAT is under our control, and we know that 0/0/0 -> WB. The host
MTRR is mostly under dom0 control, but it had better not screw with the
types for E820_RAM areas, as that could crash the whole system. So we can
assume that any RAM regions are WB in the MTRR (i.e., should be left as the
BIOS set it up). So we do *not* need to add any extra logic for
non-pass-thru domains, as they map nothing but ordinary RAM. If these basic
assumptions are wrong then we would need to worry about PV domain mappings,
and Xen's own mappings, as well!

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).

In light of all this, messing with attribute logic for non-pass-thru domains
before 3.2.0 is released is not going to fly.

 -- Keir



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