Just for documentation,
heat sink reassembled using normal grey cpu thermal grease


On July 25, 2021 4:30:39 PM GMT+02:00, Ludwig Jaffe <luja@openhardware.de> 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@invisiblethingslab.com> 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?
>>
>>-- 
>>Best Regards,
>>Marek Marczykowski-Górecki
>>Invisible Things Lab
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.