Re: [Xen-devel] [PATCH 8/8] x86/EPT: IOMMU snoop capability should not affect memory type selection

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Friday, April 04, 2014 4:28 PM
> 
> >>> On 04.04.14 at 09:30, <kevin.tian@xxxxxxxxx> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: Thursday, March 27, 2014 11:33 PM
> >>
> >> >>> On 27.03.14 at 16:12, <tim@xxxxxxx> wrote:
> >> > At 15:37 +0000 on 26 Mar (1395844658), Jan Beulich wrote:
> >> >> This capability solely makes a statement on cache coherency guarantees
> >> >> by the IOMMU. It does specifically not imply any further guarantees
> >> >> implied by certain memory types (cachability, ordering).
> >> >
> >> > Can you give some examples of what this is protecting against?
> >> >
> >> > Cachability is irrelevant unless there's some other form of direct
> >> > access that's not covered by the IOMMU, and x86 ordering is pretty
> >> > strict.
> >>
> >> What the IOMMU gets to see already depends on cachability: Especially
> >> for write buffers (WC) I don't think cache coherence really matters.
> >>
> >> And my understanding of "snoop" also means that stuff held in caches
> >> (WB) may not become visible as needed when some RAM page is
> >> shared between CPU and some device (namely a GPU): The IOMMU
> >> can certainly snoop any accesses that hit the bus, but I don't think it
> >> can enforce write-back to happen for an area that's marked WB but
> >> was supposed to be UC. But maybe I'm wrong with this...
> >>
> >
> > WC is essentially a UC type, with only difference on caching writes in
> > a store buffer. The out-of-order implication means that WC is only used
> > for I/O buffers w/o write order requirements, e.g. frame buffer. GPU
> > access to frame buffer is not snooped, or more specifically, it may use
> > a different physical address (through GPU page table), which is different
> > from the address written by CPU (typically a PCI bar). Using WB on pages
> > which are supposed to WC doesn't work.
> 
> Which isn't answering the original question (or at least I'm not able
> to derive the answer from your statement above): Is this patch (or
> parts thereof) correct?

OK with the change in epte_get_entry_emt, but I'm still thinking whether 
there's correctness issue about cr0.cd handling in original logic.

> 
> > However, in virtualization WC may be used on memory pages, e.g. a
> > virtual frame buffer provided by Qemu. In that scenario WC must be
> > replaced with WB, otherwise there's cache inconsistency problem when
> > Qemu accesses virtual frame buffer as WB while guest uses WC.
> 
> But that's being taken care of already by qemu pinning the memory
> attribute of the frame buffer to WB. I.e. we need to only be concerned
> of pass-through cards' frame buffers (and alike).
> 

yes.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel