[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |