Test 822 feels weird

[hrw]

Test 822 reads value from PCIe and compares it with expected values:

  /* Derive bit-field of interest from the register value */
  val_pcie_read_cfg(bdf, cap_base + reg_offset, &reg_value);

  /* To prevent status bits are clear when write 1, just clear it firstly */
  val_pcie_write_cfg(bdf, cap_base + reg_offset, reg_value);
  val_pcie_read_cfg(bdf, cap_base + reg_offset, &reg_value);

  bf_value = (reg_value >> REG_SHIFT(alignment_byte_cnt, bf_entry->start)) &
                    REG_MASK(bf_entry->end, bf_entry->start);

  /* Check if bit-field value is proper */
  if (bf_value != bf_entry->cfg_value)
  {
      val_print(ACS_PRINT_ERR, "\n       BDF 0x%x : ", bdf);
      val_print(ACS_PRINT_ERR, bf_entry->err_str1, 0);
      val_print(ACS_PRINT_ERR, ": 0x%x", bf_value);
      val_print(ACS_PRINT_ERR, " instead of 0x%x", bf_entry->cfg_value);
      if (!val_strncmp(bf_entry->err_str1, "WARNING", WARN_STR_LEN))
          return 0;
      return 1;
  }

Test fails here:

       BDF 0x400 : SLT attribute mismatch: 0xFF020100 instead of 0x20100
       BDF 0x500 : SLT attribute mismatch: 0xFF030300 instead of 0x30300
       BDF 0x600 : SLT attribute mismatch: 0xFF040400 instead of 0x40400

(and so on for each card in system)

But if I add lines to show value of reg_value variable it shows expected values:

HRW    BDF 0x400 : REG: 0x20100
       BDF 0x400 : SLT attribute mismatch: 0xFF020100 instead of 0x20100
HRW    BDF 0x500 : REG: 0x30300
       BDF 0x500 : SLT attribute mismatch: 0xFF030300 instead of 0x30300
HRW    BDF 0x600 : REG: 0x40400
       BDF 0x600 : SLT attribute mismatch: 0xFF040400 instead of 0x40400

Where a problem is? My emulated system or bsa acs?

[gowthamsiddarthd]

Hi @hrw,

Two types of checks are conducted for register verification: data and attribute validation.

Regarding the SLT (Secondary Latency Timer) register, the expected values align with the ACS specifications, registering as 0. However, a discrepancy arises in the register's attribute, intended to be set as Read-Only. Contrary to this intent, the bit field seems to function as Read-Write. Ordinarily, when attempting to write to the register by configuring all bits to 1, the anticipated behavior should involve rejecting the write operation, maintaining the value at 0 to uphold the register's designated Read-Only nature. However, in this scenario, the write action takes effect, leading to a transformation of the register's value to FFs. This anomaly could potentially stem from an issue within the emulator.

To clarify, could you confirm whether these error behavior descriptions do not pertain to the PCIe-to-PCI-PCI-X Bridge?

Regards, ACS Team

[hrw]

It was a bit of time since last time I was looking at BSA ACS code. Have to check which cards it ignores.

Here is complete log from running BSA ACS: sbsa-ref-log-822.txt

A few days old QEMU and EDK2 with ITS patches.

[hrw]

~ # lspci -nn
00:00.0 Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge [1b36:0008]
00:01.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
00:02.0 Display controller [0380]: Device [1234:1111] (rev 02)
00:03.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
00:04.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
00:05.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
00:06.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
00:07.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
00:08.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
00:09.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
00:0a.0 Host bridge [0600]: Red Hat, Inc. QEMU PCIe Expander bridge [1b36:000b]
01:00.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c]
02:00.0 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02)
03:00.0 Non-Volatile memory controller [0108]: Red Hat, Inc. QEMU NVM Express Controller [1b36:0010] (rev 02)
04:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
05:00.0 USB controller [0c03]: Red Hat, Inc. QEMU XHCI Host Controller [1b36:000d] (rev 01)
06:00.0 Unclassified device [00ff]: Red Hat, Inc. Virtio 1.0 RNG [1af4:1044] (rev 01)
07:00.0 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000e]
08:09.0 Multimedia audio controller [0401]: Ensoniq ES1370 [AudioPCI] [1274:5000]
~ # lspci -tv
-[0000:00]-+-00.0  Red Hat, Inc. QEMU PCIe Host bridge
           +-01.0  Intel Corporation 82574L Gigabit Network Connection
           +-02.0  Device 1234:1111
           +-03.0  Intel Corporation 82576 Gigabit Network Connection
           +-04.0-[01-02]----00.0-[02]----00.0  Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode]
           +-05.0-[03]----00.0  Red Hat, Inc. QEMU NVM Express Controller
           +-06.0-[04]----00.0  Intel Corporation 82576 Gigabit Network Connection
           +-07.0-[05]----00.0  Red Hat, Inc. QEMU XHCI Host Controller
           +-08.0-[06]----00.0  Red Hat, Inc. Virtio 1.0 RNG
           +-09.0-[07-08]----00.0-[08]----09.0  Ensoniq ES1370 [AudioPCI]
           \-0a.0  Red Hat, Inc. QEMU PCIe Expander bridge

[gowthamsiddarthd]

Hi @hrw,

Thank you for providing the logs. The analysis has confirmed that the BDFs belong to Rootport. In the context of Rootports, these bits should ideally be read-only. The error appears to be an emulator issue.

Regards, Gowtham The ACS team

[hrw]

Thank you @gowthamsiddarthd - will discuss it with QEMU developers.

[hrw]

https://lore.kernel.org/qemu-devel/56aa4acb-d54c-a457-5a32-9258cec1ac96@linaro.org/