Re: PCIe: SLT attribute mismatch: 0xFF020100 instead of 0x20100

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 29 Aug 2023 at 12:40, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
>
> I am working on aarch64/sbsa-ref machine so people can have virtual
> machine to test their OS against something reminding standards compliant
> system.
>
> One of tools I use is BSA ACS (Base System Architecture - Architecture
> Compliance Suite) [1] written by Arm. It runs set of tests to check does
> system conforms to BSA specification.
>
> 1. https://github.com/ARM-software/bsa-acs
>
>
> SBSA-ref goes better and better, yet still we have some issues. One of
> them is test 822 ("Check Type 1 config header rules") which fails on
> each PCIe root port device:
>
> 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
>
> I reported it as an issue [2] and got response that it may be QEMU
> fault. My pcie knowledge is not good enough to know where the problem is.
>
> 2. https://github.com/ARM-software/bsa-acs/issues/193
>
>
> In the comment Gowtham Siddarth wrote:
>
> > 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 behaviour
> > 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.
>
> Does someone know where the problem may be? And how to fix it?

I don't know enough about PCI to be sure here, but it sounds like
what you're saying is happening is that the test case writes all-1s
to some PCI register for the root port device, and expects that where
some bits in it are defined in the spec as read-only they don't get set?

Which registers exactly is the test case trying to write in this way ?

I've cc'd the QEMU PCI maintainers.

thanks
-- PMM