Xen project Mailing List

On July 25, 2021 4:30:39 PM GMT+02:00, Ludwig Jaffe <luja@xxxxxxxxxxxxxxx> wrote:

Hi Marek, as you are refered as Xen expert I thought you are the only one in the qubes project to know about it.
Hi people at Xen, it would be nice to add override options in such code for test purposes something like forceiommu=1

So disassembling the cooler the chip reads
"SLH3P" the errata sheet refers it to C2 stepping and states it supports Intel Trusted Execution TXT.
This is on page 11 (3rd line of table) of said intel errata.

So things get a bit wired. Having an override in the kernel boot flags would surely help
to bring the computer up with cubes as it should be supported according to yhe laser markings. Maybe the pci-revisions are writen into registers of the host bridge at the time the bios does pci(e) config cycles and a buggy bios could simply write buggy pci revisions (just an assumption). Laser markings on the die should be trusted.

Regards,

luja

On July 25, 2021 3:55:52 PM GMT+02:00, "Marek Marczykowski-Górecki" <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:

On Sun, Jul 25, 2021 at 02:31:17PM +0200, luja wrote:
Hi Marek, Hi all,

Hi luja,

First of all, please use appropriate mailing list for such emails, not
email individual developers privately. I'm adding xen-devel here.


On a HP Z600 I am trying to run qubes.
The Xen log says that the Chipset is affected by Intel-Errate #47, #53

the code in Xen is this:

"
/* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
* Fixed in stepping C-2. */
static void __init tylersburg_intremap_quirk(void)
{
uint32_t bus, device;
uint8_t rev;

for ( bus = 0; bus < 0x100; bus++ )
{
/* Match on System Management Registers on Device 20 Function 0 */
device = pci_conf_read32(0, bus, 20, 0, PCI_VENDOR_ID);
rev = pci_conf_read8(0, bus, 20, 0, PCI_REVISION_ID);

if ( rev == 0x13 && device == 0x342e8086 )
{
printk(XENLOG_WARNING VTDPREFIX
"Disabling IOMMU due to Intel 5500/5520/X58 Chipset errata #47, #53\n");
iommu_enable = 0;
break;
}
}
}

"

But! rev 0x13 is not suficient to detect the "wrong" host bridge.

According to the spec by Intel (page 11 in the PDF you attached), it is.

This Z600 is equipped with 0B54h mainboard as can be seen with dmi-decode.

The manual states that 0B54h mainboard has the "newer C2 stepping",
so it is *not* affected by Intel "spec update" (nota bene: Intel updates the
spec, others report erratas) bugs  

The code above checks for rev 0x13, and the spec (page 11) clearly says that rev
0x13 is stepping B-3. Stepping C-2 is rev 0x22. So, if this check
triggers for you, I'm afraid you have the affected chipset.

According to HP doc you attached, you can additionally confirm it via
BIOS:
    To determine if a specific HP Z600 system
    has the C2 revision of the chipset:
    1. Use the BIOS setup menu to access the “Boot
    Block Date” from the “System Information Menu.”
    All B3-based systems will have a “1/30/09”
    date and C2-based systems will have a
    “01/07/10” date.

So the way Xen detects the "bug" (pci rev 13) is not sufficient, as my Z600
shows pci rev13 with lspci but 0xB54h (board rev only on Z600) with dmidecode
I would suggest first to have an override xen kernel boot option to disable the disablement in this code section. Or just patch this part out of the Xen code and rebuild xen. If this stuff really crashes, one will see it.

Patching it out is out of the question, this check if there for a
reason.

So please build a new xen without this stupid disablement or please add an override boot command for it.

Please see the attached upgrade manual of Z600 and the errata "spec update" by Intel.
You see that the C2 stepping is not affected by the bugs refered to in the xen code,
so removing that section or adding better detection of the mask revision (B3 vs. C2)  of 5520 host bridge would allow  many users to operate Qubes4.

Maybe someone else has an alternative idea?

Re: Xen-Error: Disabling IOMMU on Stepping C2 5520 Host-Bridge // Laser markings: SLH3P