Re: [Xen-devel] [PATCH] VT-d: add iommu=igfx_off option to workaround graphics issues

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.07.15 at 09:23, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Tuesday, July 21, 2015 3:17 PM
>  
>> >>> On 21.07.15 at 09:05, <kevin.tian@xxxxxxxxx> wrote:
>> >>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> >> Sent: Tuesday, July 21, 2015 2:57 PM
>> >> >>> On 21.07.15 at 02:57, <kevin.tian@xxxxxxxxx> wrote:
>> >> >>  From: Andrew Cooper [mailto:amc96@xxxxxxxxxxxxxxxx] On Behalf Of 
>> >> >> Andrew
>> >> > Cooper
>> >> >> Sent: Monday, July 20, 2015 4:21 PM
>> >> > This is the part which I don't quite understand. WC is essentially an UC
>> >> > attribute with write buffer to accelerate the write efficiency. There
>> >> > should be no correctness problem to use either WC or UC if i915 driver
>> >> > wants WC.
>> >>
>> >> "Should" is too weak a term here: Using WC on the wrong piece of
>> >> memory or without the necessary fencing can imo very well cause
>> >> correctness problems (which would be hidden by WC -> UC
>> >> conversion behind the driver's back).
>> >>
>> >
>> > My point is about when i915 wants WC, then either UC (I suppose is
>> > the case before that Linux commit) and WC (by that commit) has
>> > no correctness problem. UC is more strict than WC. It's just performance
>> > difference. It's not about using WC in wrong place when it's not desired.
>> 
>> In this you assume there are no misguided attempts to request
>> WC in the driver, which would have gone unnoticed as long as WC
>> didn't become the effective attribute. And "misguided" here is
>> meant to include cases where hardware errata may need taking
>> care of.
> 
> I don't understand this point. If it's misguided attempts it'd be
> same on bare metal. 

Not if bare metal has a workaround in place depending on (or even
implemented in) IOMMU code. Also iirc the reported said that a
similar problem existed (exists?) on native too.

Jan


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