
Hi,
The issue is happening in the following scenario. 1) Launch the QEMU for RISCV virt platform with uboot and ubuntu OS (Host system). Now the OS is booted without any issue. 2) Enable the KVM in the ubuntu OS. 3) Create a VM by launching the same RISC V QEMU from the Ubuntu OS (Host system) after enabling KVM. 4) So now the qemu is running from the HOST OS and launching the uboot and then OS. The system crash is happening in the VM OS booting. If the FDT is reserved with stub bytes then the VM is launched properly.
The issue is not happening while launching Host OS even if it use the same uboot code. As per the image_fdt code in uboot, the FDT size is blindly increased even if the relocation is disabled and updated in the FDT header. So i reserve the Padding bytes while reserving FDT in uboot board_f phase itself for adding bootargs in uboot after image_fdt.
Regards, Selva
On Sat, Feb 10, 2024 at 1:55 AM Tom Rini trini@konsulko.com wrote:
On Fri, Feb 09, 2024 at 07:45:10PM +0530, Selvakumar Velandi wrote:
The FDT relocation is not disabled. I am adding the FDT PADDING bytes
while
doing FDT reservation in the board_f file. Also update the FDT length based on the new allocation, instead of
blindly
increasing the size. Currently the size is getting increased even for the relocation disabled scenario also. So without increasing the physical memory for the disable relocation use case, the fdt total size is updated. thus causing memory corruption
Please explain on what system you're seeing this with, and how things are configured and what else is required to trigger this problem. Your changes to boot/image-fdt.c change things so that we don't pad the non-relocated device tree (but we need to, we still change the bootargs and so forth). And the changes to common/board_f.c look like we're trying to do that instead, earlier? But we should not have a kernel corruption problem unless:
- We aren't relocating the device tree
- We aren't relocating the device tree far enough away from the kernel, but this shouldn't be a problem on arm64 and riscv where the Image header structure tells us how big the BSS is to be and we obey that.
-- Tom