[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 8/8] x86/EPT: IOMMU snoop capability should not affect memory type selection
>>> On 04.04.14 at 11:21, <kevin.tian@xxxxxxxxx> wrote: >> 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. Okay, let us know of the outcome. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |