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

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

Keir Fraser <mailto:Keir.Fraser@xxxxxxxxxxxx> wrote:
> On 8/10/07 16:29, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
> 
>> For RAM assigned to guest, the patch will allow non-WB types. The
reason
>> is for following scenerio: A  PCI-E device setting the non-snoop bit
to
>> 1 in TLP header when doing memory access transaction to RAM. and the
>> driver/OS will access that RAM with UC attribute.
>> 
>> In current implementation without this patch, WB type will be used by
>> guest, then PCI-E device may get wrong data, becaues the data updated
>> by CPU may still in cache, and the PCI-E device's access is not
snooped.
>> This patch will virtualize the cache attribute through attribute in
>> shadow page table.
> 
> 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 there are reservations about how this will interact with mappings
in
> qemu-dm, perhaps this new attribute mechanism should only be
> enabled for
> pass-thru domains? We get no benefit for non-pass-thru domains and
some
> concern about correctness. 

I think interact with qemu-dm should be ok, since we knows about which
range is VRAM from QEMU. One method is, qemu notify xen, which guest RAM
range's attribute will set according to host type, not gust type.

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.

> 
> -- Keir

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