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 <tr...@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 > -- *** This communication is confidential, may be privileged and is meant only for the intended recipient and purpose. No part of this email or any files transmitted with it can be shared, copied, forwarded or published online or offline, without prior written consent of the sender. If you are not the intended recipient, please preserve the confidentiality, delete the e-mail and attachments, if any from your system and inform the sender immediately. ***