Re: [Xen-devel] XSA-59

["Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>]

I did find your updated patch (I really can blame Outlook for not finding it 
the first time) and yes, that patch is correct.  Yes, the patch contains a 
complete list of all the PCI IDs that are affected by this quirk.

Unfortunately, there is no publicly published write-up on this issue at this 
time, I'm looking into what can be done about that.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Jan Beulich [mailto:JBeulich@xxxxxxxx] 
Sent: Monday, March 10, 2014 1:37 AM
To: Dugger, Donald D
Cc: Mallick, Asit K; Liu, Jinsong; Li, Susie; Auld, Will; Wang, Yong Y; 
Bulygin, Yuriy; xen-devel@xxxxxxxxxxxxx
Subject: RE: XSA-59

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