[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.