On Mon, 1 Jul 2024 at 07:49, Marcin Juszkiewicz <marcin.juszkiew...@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.juszkiew...@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
