On 4/16/24 08:11, Jonathan Cameron wrote:
On Fri, 1 Mar 2024 10:41:09 -1000
Richard Henderson <richard.hender...@linaro.org> wrote:
If translation is disabled, the default memory type is Device, which
requires alignment checking. This is more optimally done early via
the MemOp given to the TCG memory operation.
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reported-by: Idan Horowitz <idan.horow...@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Hi Richard.
I noticed some tests I was running stopped booting with master.
(it's a fun and complex stack of QEMU + kvm on QEMU for vCPU Hotplug kernel
work,
but this is the host booting)
EDK2 build from upstream as of somepoint last week.
Bisects to this patch.
qemu-system-aarch64 -M virt,gic-version=3,virtualization=true -m
4g,maxmem=8G,slots=8 -cpu cortex-a76 -smp cpus=4,threads=2,clusters=2,sockets=1
\
-kernel Image \
-drive if=none,file=full.qcow2,format=qcow2,id=hd \
-device ioh3420,id=root_port1 -device virtio-blk-pci,drive=hd \
-netdev user,id=mynet,hostfwd=tcp::5555-:22 -device
virtio-net-pci,netdev=mynet,id=bob \
-nographic -no-reboot -append 'earlycon root=/dev/vda2 fsck.mode=skip
tp_printk' \
-monitor telnet:127.0.0.1:1235,server,nowait -bios QEMU_EFI.fd \
-object memory-backend-ram,size=4G,id=mem0 \
-numa node,nodeid=0,cpus=0-3,memdev=mem0
Symptoms: Nothing on console from edk2 which is built in debug mode so is
normally very noisy.
No sign of anything much happening at all :(
This isn't a fantastic bug report.
(1) If it doesn't boot efi, then none of the -kernel parameters are necessary.
(2) I'd be surprised if the full.qcow2 drive parameters are necessary either.
But if they are, what contents? Is a new empty drive sufficient, just
enough to send the bios through the correct device initialization?
(3) edk2 build from ...
Well, this is partly edk2's fault, as the build documentation is awful.
I spent an entire afternoon trying to figure it out and gave up.
I will say that the edk2 shipped with qemu does work, so... are you absolutely
certain that it isn't a bug in edk2 since then? Firmware bugs are exactly what
that patch is supposed to expose, as requested by issue #1204.
I'd say you should boot with "-d int" and see what kind of interrupts you're getting very
early on. I suspect that you'll see data aborts with ESR xx/yy where the last 6 bits of
yy are 0x21 (alignment fault).
r~
