|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] XSA-59
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.
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--- Begin Message --- _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |