[Xen-devel] RE: [PATCH][VTD][QUIRK] added quirks for Sandybridge errata workaround, WLAN, VT-d fault escalation

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 19.01.11 at 01:12, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
>>  Isn't there a risk that these MMIO writes interfere with the
>> operation of the actual driver running in a domain?
> 
> I have checked drivers/gpu/drm/i915/i915_reg.h in the kernel and I don't see 
> any usage of these MMIO registers.  Do you think we should add a boot switch 
> to allow optionally turn off these workarounds just in case?  If so, what 
> default value should it be?

Not sure. A fundamental question is whether these registers could
ever be of use to a driver (and if they wouldn't, I would wonder why
they're there).

One thing that might help at least detect possible collisions could be
to read the state prior to writing it in the preamble code, and check
whether it matches expectations (and perhaps force to known
values during initialization).

>> And even just in Xen itself, how do these writes get
>> synchronized? Callers of vtd_ops_preamble_quirk() don't
>> appear to be required to hold any particular lock.
> 
> I have added a igd_lock in the attached patch.  Can you take a look?

That doesn't really look sufficient. You could still have multiple CPUs
going through these code paths simultaneously, and e.g. CPU A
executing snb_vtd_ops_postamble() while CPU B still wants the
result of snb_vtd_ops_preamble() in effect.

To me it would seem more logical to add a usage counter: When
transitioning from zero, suppress RC6, and when transitioning to
zero, re-enable RC6 (whatever this is). If what gets written in
the preamble is some sort of counter the hardware decrements,
you would need to extend the period each time execution flows
through the preamble.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel