[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.