[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH 0/2] MTRR/PAT virtualization
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote: > > Given that this is probably only safe for non-RAM pages, and given > that usually such mappings will be UC anyway, is there any advantage > to this large patch except accelerated access to passed-through video > framebuffer access? The current 'collapse all memory types to UC for > non-RAM mappings' > is I believe always safe, Propogating guest memory type for MMIO only is what I posted last year which is rejected by you since pass-through devices support are not in at that time :-( But later on, with VT-d enabled, we found this is insufficient. We know some audio drivers will use non-snoopy + UC map for RAM buffers, and same for video batch buffers in addition to vram buffer. We have to propogating guest RAM memory type too to fix the audio/video issues :-( > Won't WBINVD and CLFLUSH also need to be virtualised? Basically native OS can use WB + WBINVD scenario for output buffer, but can't be used as input buffer. I doutb if a driver will use different memory attribute for input/output buffer. But, yes this is really a good point. So we need to do WBINVD when VP migrates (of course for pass-through domain only), while the prefered approach is to pin VCPU on pCPUs. > > 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. Yes, we can do in this way. > about Xen's own full 1:1 WB mapping of all RAM (x86/64 Xen > only of course). For a native OS, will OS unconditionally map the whole memory itself? I think no, otherwise same issue will happen to native OS. BTW, if we don't remove those fixed 1:1 mapping, even without MTRR patch, we may meet problem in future when there are complicated drivers in domain0. E.g. high end graphics driver in domain0 may use UC for its batch buffer, same for audio driver and other PCIe drivers in future. Processor will see 2 different memory attribute in its direct page table. So I think Xen need to take same policy like native OS though it may be painful. With Xen moving to client, those issue will become more popular. > 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 Do u mean AMD processor support speculative write? I don't think Intel processor support this. > 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. I may lose here. The MTRR patch only tighten the memory access attribute, never loosen it, so we are toward much safer direction, isn't it? Anyway, we can split the patch into 2, one for MMIO only and another one for both with RAM. Probably the patch is almost same, just one line to eliminate the RAM mmeory type propogatio. Thanks, eddie _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |