Re: [Xen-devel] XSA-59

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.14 at 05:16, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> Q3: the "...  without AER capability?" warning triggers on Jan's systems --> 
> is 
> it an issue? or, how to handle it properly?
> [Asit] BIOS can have option to not expose AER capability. It will be good to 
> check the BIOS setup options. The error reporting should be masked so not 
> action needed.
> [Yuriy] I expanded the answer to Q3 vs. what's in the attached email after 
> we found out that when root port is operating in DMI mode, AER ext. 
> capability is not in the chain of ext. capability headers. Please use this 
> one instead.
> Answer to Q3:
> On Romley system (DID 0x3c00 ... 0x3c0b), for Host bridge BDF=00:00.0, when 
> the root port is operating as DMI, AER extended capability is defined in 
> VSHDR (Vendor Specific Header) configuration register (offset 0x148). It 
> should have value 0x0004.
> After pci_find_ext_capability, if it didn't find AER capability, for 
> BDF=00:00.0 the patch would need to check if VSHDR register has value 0x0004 
> in bits [15:0].
> Below I've provided example fix for this case:
>     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;           
>                 }


If we get here, pos needs to have a proper value - what would that
be?

> Q4: the patches have no way of handling future chipsets (yet we also have no 
> indication that future chipsets would not exhibit the same bad behavior) --> 
> thoughts?
> [Jinsong] IMHO handle future chipset case by case.

Ugly. And hard to believe that over this extremely long time it
took you (as a company) to come back there were no new
additions to either of the two sets of PCI IDs that need dealing
with.

> BTW, some other infromation from Yuriy:
> VT-d-mask-UR-host-bridge.patch:
> 1. The workaround is only applicable to the host bridge device 00:00.0 
> (DMIBAR does not exist for other devices). The patch is written generically 
> for any PCIe device/bridge.

Does that mean that all other devices would have the respective
signal filtered by the host bridge if that one has UR signaling
masked?

That would reduce the number of PCI IDs needing dealing with,
wouldn't it? In which case we'd need to know which ones to care
about (I'd guess just 0x3400 and 0x3c00), and whether we in
fact need to check bdf (see the older workaround dealing with
0x342e and 0x3c28, which don't check where in the topology they
live either).

> 2. The workaround is only needed when SERR is enabled. As there will be only 
> a fraction of client systems with SERR enabled, it might be worthwhile to 
> only apply it when SERRE is 1.
>    val = pci_conf_read16(seg, bus, dev, func, PCI_COMMAND);
>    if ( val & PCI_COMMAND_SERR )
>      apply this workaround

But SERR may get enabled subsequently by the Dom0 kernel. I'd
rather not leave that case un-addressed.

Jan


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