Re: [Xen-devel] XSA-59

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

Liu, Jinsong wrote:
> Jan,
> 
> For XSA-59, I list some questions (coming from your patches and
> emails) and consult Intel inside from different groups. 
> 
> Below are the questions and replies (Q2 still not got answer):
> Q1: is the PCI IDs list (0x3400 ...) of root port a complete list?
> Jan got it from a disclosure that Intel made to him meanwhile well
> over-two-years-ago --> Any update about the list? [Asit]: There is
> not update to this list. This was provided in 2011 and included the
> Ids prior to being fixed.   
> 
> 
> Q2: is the PCI IDs list (0x100 ...) of host bridge a complete list?
> it comes from Yuriy but Jan need double confirm 'a complete list'. 
> 
> 
> 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;
>                 }
>             }
>             else
>             {
>                 printk(XENLOG_WARNING "%04x:%02x:%02x.%u without AER
>                 capability?\n", seg, bus, dev, func); break;
>             }
>         }
> 
> 
> 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.  
> 
> 
> Q5: please clarify whether masking the reporting of unsupported
> requests is really an appropriate thing to do: After all, this masks
> not only maliciously created instances of them, but also any ones
> possibly resulting from malfunctioning hardware. [Yuriy] Most of the
> client systems don't have SERR enabled (not recommended
> configuration). For server systems, I don't know the answer to this
> question as our team didn't work on the issue and workaround for it
> when it was defined. You'd need to ask Rajesh.  

Sorry, cc Rajesh.

Thanks,
Jinsong
    
> 
> 
> 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.  
> 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 
> 
> 
> Thank you all,
> Jinsong


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