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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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