WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH][VTD][QUIRK] added quirks for Sandybridge errata workaround, WLAN, VT-d fault escalation
From: "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Date: Wed, 19 Jan 2011 15:40:55 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>
Delivery-date: Wed, 19 Jan 2011 15:41:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D36C02C020000780002D140@xxxxxxxxxxxxxxxxxx>
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> <4D36C02C020000780002D140@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acu3vS81+v6H0CemRy+hGqsopZ7mlAAdDUmQ
Thread-topic: [PATCH][VTD][QUIRK] added quirks for Sandybridge errata workaround, WLAN, VT-d fault escalation
> 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.

I see what you are getting at ...  Another alternative is to simply putting the 
lock around the "preamble->iotlb_flush->postamble" sequence in iommu.c.  It 
spills more of the quirk specific code into iommu.c but this should be much 
simpler logic wise.  What do you think?

Allen


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