This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: [PATCH][VTD][QUIRK] added quirks for Sandybridge errata

To: "Allen M Kay" <allen.m.kay@xxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH][VTD][QUIRK] added quirks for Sandybridge errata workaround, WLAN, VT-d fault escalation
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 19 Jan 2011 09:42:52 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>
Delivery-date: Wed, 19 Jan 2011 01:43:14 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <987664A83D2D224EAE907B061CE93D53019420D863@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <987664A83D2D224EAE907B061CE93D530194107F82@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D357035020000780002CD64@xxxxxxxxxxxxxxxxxx> <987664A83D2D224EAE907B061CE93D53019420D863@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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.


Xen-devel mailing list