Re: [Xen-devel] XSA-59

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.03.14 at 00:04, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx> wrote:
> Q3:  Below is code (hopefully complete) that will check a Romley system and 
> verify that the VSHDR register is correct:
> 
>     case 0x3c00 ... 0x3c0b:
>         pos = pci_find_ext_capability(seg, bus, pdev->devfn,
>                                       PCI_EXT_CAP_ID_ERR);
>         if ( !pos )
>         {
>             if ( 0 == bus && 0 == pdev->devfn )
>             {
>                 dmi_aer_cap_id = pci_conf_read16(seg, 0, 0, 0, 0x148) // DMI 
> Specific AER Capability ID
>                 if ( 0x0004 != dmi_aer_cap_id )
>                 {
>                     printk(XENLOG_WARNING "%04x:%02x:%02x.%u without AER 
> capability?\n", seg, bus, dev, func);
>                     break;
>                 }
>             }
>             else
>             {
>                 printk(XENLOG_WARNING "%04x:%02x:%02x.%u without AER 
> capability?\n", seg, bus, dev, func);
>                 break;
>             }
>         }

This looks to be the same code that was suggested in the response
to the first version of the patch. Meanwhile I had posted a second
version, incorporating some feedback, and doing the above without
hard coding register numbers. I'd really appreciate feedback on the
latest version.

Furthermore, afaict this is still inconsistent with earlier feedback
comments: This continues to deal with both host bridges and root
ports, despite Yuriy having indicated only host bridges would need
this applied (as long as we go with the global disable).

> Not sure your concern about versions, the code is checking for BDF 0:0.0, 
> that should be sufficient.
> 
> Q4: I don't quite understand your comment about never being able to put this 
> to rest.  We've identified those chipsets that have the problem and created a 
> quirk for them.  We've fixed the problem in follow on chipset and our goal is 
> to keep the issue fixed in all future chipsets.

Have you? The data sheets for newer processors/chipsets (PCI IDs
of which I had added to the second patch revision) don't seem to
match up with that (albeit I admit that the specific case of how
bogus MSI message writes get dealt with isn't explicitly mentioned
anywhere I could find). I'd be happily removing those IDs again
though, if the issue indeed got fixed on newer ones, but I'd like
this to be confirmed by some kind of (hopefully publicly accessible)
documentation.

Jan


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