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.
> 
Thank you I'll see if I can find an online version to point others to, but
regardless, errata 61 seems to be the kicker here.  Looks like we need to add
and new pci id to the quirk, and check for some additional revisions if that one
is seen.  I'll get to it shortly.  Thanks for sending this out.  Lets hope this
problem doesn't exist in even more chipsets.
Neil


> > 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.
> 
> Jan
> 



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