Re: [Xen-devel] VT-d interrup remapping errata workaround

[Neil Horman <nhorman@xxxxxxxxxxxxx>]

On Mon, Jul 08, 2013 at 02:42:55PM +0100, Jan Beulich wrote:
> >>> On 08.07.13 at 15:33, Neil Horman <nhorman@xxxxxxxxxxxxx> wrote:
> > On Mon, Jul 08, 2013 at 01:29:43PM +0100, Jan Beulich wrote:
> >> All,
> >> 
> >> just having spotted the backport of Linux commit 03bbcb2e I notice
> >> a certain discrepancy with the Xen commit having the same purpose
> >> as well as with the actual specification updates:
> >> 
> >> The Linux solution keys off of device IDs 3403 and 3406, as listed in
> >> the specification update, but this way fails to cover the X58 chipset,
> >> which has - under different numbers (62 and 69) - the same errata
> >> (the Linux commit message also only mentions erratum 53 for the
> >> 55x0 chipsets, albeit I believe 47 is as much of an issue there as it is
> >> for Xen).
> >> 
> >> The Xen solution keys off of ID 342e, with no explanation in the
> >> commit description on where this association comes from.
> >> 
> >> I therefore wonder whether
> >> - the Xen solution may have false positives
> >> - the Linux solution would still have false negatives even after
> >>   adding ID 3405
> >> 
> > Don Dutile noted that there was a problem he thought he noted with an X58
> > chipset that was simmilar to the one I fixed in the above commit.  I'm 
> > unabel to
> > track down an errata sheet for the X58 chipset, but if you have one and can
> > forward it to me I think it would be best (assuming that it has the same 
> > errata
> > that the 5500/5520 chipsets do), that we just add their pci device id's in 
> > to the existing linux errata.
> 
> Attached. I don't have a weblink at hand, I'm sending a copy cached
> on my local FS.
> 
> > To answer your above questions, I'm not sure if the xen solution may offer 
> > false
> > positives, as I've not looked at the code.  The Linux solution may offer 
> > false
> > negatives, but only to the extent that this problem exists in chips not 
> > covered
> > by any errata sheet that I've found to date. 
> 
> Yeah, the hidden question behind that really was - do we have a
> way to ensure no false negatives and no false positives? I.e. some
> consolidated set of errata listing not just an individual chipset's
> revisions that are affected, but all chipsets with all their revisions.
> I already proded my Intel contacts for this, but am of little hope
> that I'll get back a positive answer.
> 
Its a limitation of the organizational system.  Errata sheets are filed
per-device, so you have to look at each devices sheet to know if its affected,
and its on us to add devices to the appropriate quirks manually.

I wouldn't hold out for Intel on this either.  They can help if you point to a
specific device and errata item, but they don't have a database thats searachble
by errata text super easily.
Neil

> Jan
> 



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