[PATCH] Added FDT PAD memory size while reserving memory for FDT to avoid some memory corruption issue
Hi,
Issue: Linux kernel getting crash after loading kernel in VM system using RISCV QEMU.
RootCause: Memory corruption in uboot FDT memory while launching a VM system in RISCV QEMU.
Fix: In the board_f.c file the FDT memory region is reserved without FDT padding bytes. uboot will add some params like bootargs while launching linux. While relocate the FDT, if its decided as run in the Fixed memory location i.e fdy_high is set as -1, then the padding bytes not added while relocating the FDT, but the size is blindly added with padding bytes without reserving the physical memory in the FDT header in the image_fdt.c file.
Please find the attached patch file to fix the issue. Please review and revert your comments.
Regards, SelvakumarVelandi Krutrim SI designs
On Fri, Feb 09, 2024 at 01:22:08PM +0530, Selvakumar Velandi wrote:
Hi,
Issue: Linux kernel getting crash after loading kernel in VM system using RISCV QEMU.
RootCause: Memory corruption in uboot FDT memory while launching a VM system in RISCV QEMU.
Fix: In the board_f.c file the FDT memory region is reserved without FDT padding bytes. uboot will add some params like bootargs while launching linux. While relocate the FDT, if its decided as run in the Fixed memory location i.e fdy_high is set as -1, then the padding bytes not added while relocating the FDT,
Do not disable fdt relocation. The RISC-V platforms which do this today are broken.
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
On Fri, Feb 9, 2024 at 7:10 PM Tom Rini trini@konsulko.com wrote:
On Fri, Feb 09, 2024 at 01:22:08PM +0530, Selvakumar Velandi wrote:
Hi,
Issue: Linux kernel getting crash after loading kernel in VM system using RISCV QEMU.
RootCause: Memory corruption in uboot FDT memory while launching a VM system in
RISCV
QEMU.
Fix: In the board_f.c file the FDT memory region is reserved without FDT
padding
bytes. uboot will add some params like bootargs while launching linux. While relocate the FDT, if its decided as run in the Fixed memory
location
i.e fdy_high is set as -1, then the padding bytes not added while relocating the FDT,
Do not disable fdt relocation. The RISC-V platforms which do this today are broken.
-- Tom
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.
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
participants (2)
-
Selvakumar Velandi -
Tom Rini