Re: [PATCH v3 1/2] tests/avocado: update firmware for sbsa-ref

[Peter Maydell]

On Mon, 1 Jul 2024 at 07:49, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
>
> W dniu 30.06.2024 o 16:37, Ard Biesheuvel pisze:
> > On Thu, 20 Jun 2024 at 12:20, Marcin Juszkiewicz
> > <marcin.juszkiewicz@linaro.org> wrote:
> >>
> >> Update firmware to have graphics card memory fix from EDK2 commit
> >> c1d1910be6e04a8b1a73090cf2881fb698947a6e:
> >>
> >>      OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/C
> >>
> >>      Some platforms (such as SBSA-QEMU on recent builds of the emulator) 
> >> only
> >>      tolerate misaligned accesses to normal memory, and raise alignment
> >>      faults on such accesses to device memory, which is the default for 
> >> PCIe
> >>      MMIO BARs.
> >>
> >>      When emulating a PCIe graphics controller, the framebuffer is 
> >> typically
> >>      exposed via a MMIO BAR, while the disposition of the region is closer 
> >> to
> >>      memory (no side effects on reads or writes, except for the changing
> >>      picture on the screen; direct random access to any pixel in the 
> >> image).
> >>
> >>      In order to permit the use of such controllers on platforms that only
> >>      tolerate these types of accesses for normal memory, it is necessary to
> >>      remap the memory. Use the DXE services to set the desired capabilities
> >>      and attributes.
> >>
> >>      Hide this behavior under a feature PCD so only platforms that really
> >>      need it can enable it. (OVMF on x86 has no need for this)
> >>
> >> With this fix enabled we can boot sbsa-ref with more than one cpu core.
> >>
> >
> > This requires an explanation: what does the number of CPU cores have
> > to do with the memory attributes used for the framebuffer?
>
> I have no idea. Older firmware was hanging on several systems but was
> passing in QEMU tests. After closer looking I noticed that Avocado tests
> run with "-smp 1" and pass.
>
> Checked failing system with "-smp 1" and it worked. In meantime you have
> fixed problem in EDK2.
>
> So yes, updating firmware may look like hiding a bug. Which I do not
> know how to track (I can build and test QEMU, but going into its
> internals is something I never done).

My assumption was that random chance meant that TF-A when
only dealing with one CPU meant that its memory layout etc
was such that it didn't do the unaligned access. I don't think
this is likely to be a QEMU side question.

-- PMM