[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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


 


Rackspace

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