How to deal with openSBI reserved regions?

How to deal with openSBI reserved regions?

[Petr Tesarik]

Hi all,

I have recently looked into enabling crash kernel and kdump on riscv64.
I can start a new kernel after crash, but I ran into an issue when
reading /proc/vmcore there.

I am testing this inside a QEMU VM and I boot my system in S-Mode using
U-Boot with mbedded openSBI firmware. The problem here is that openSBI
occupies the first 128 pages of RAM, but they are shown as "System RAM"
in /proc/iomem. The kexec_file_load(2) system call uses
walk_system_ram_res() to build a memory map of the currently running
kernel. This is then passed to the crash kernel through ELF core headers
as a LOAD segment. When reading the corresponding part of /proc/iomem,
the crash kernel tries to map these pages, but they can be accessed only
from M-Mode. Any attempt to access them from the Linux kernel fails with
a PMP violation. Consequently, -EFAULT is returned to user space.

Now, the openSBI area is represented in the Device Tree with a
reserved-memory node () which overlaps a memory node. Technically, the
firmware region is indeed RAM, but how should it be excluded from
/proc/iomem?

Should this be fixed in the kernel?

Or, is the provided DTB incorrect?
Should the memory node exclude the firmware area?

Petr T


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: How to deal with openSBI reserved regions?

[Alexandre Ghiti]

Hi Petr,


On 28/07/2023 12:02, Petr Tesarik wrote:
> Hi all,
>
> I have recently looked into enabling crash kernel and kdump on riscv64.
> I can start a new kernel after crash, but I ran into an issue when
> reading /proc/vmcore there.
>
> I am testing this inside a QEMU VM and I boot my system in S-Mode using
> U-Boot with mbedded openSBI firmware. The problem here is that openSBI
> occupies the first 128 pages of RAM, but they are shown as "System RAM"
> in /proc/iomem. The kexec_file_load(2) system call uses
> walk_system_ram_res() to build a memory map of the currently running
> kernel. This is then passed to the crash kernel through ELF core headers
> as a LOAD segment. When reading the corresponding part of /proc/iomem,
> the crash kernel tries to map these pages, but they can be accessed only
> from M-Mode. Any attempt to access them from the Linux kernel fails with
> a PMP violation. Consequently, -EFAULT is returned to user space.
>
> Now, the openSBI area is represented in the Device Tree with a
> reserved-memory node () which overlaps a memory node. Technically, the
> firmware region is indeed RAM, but how should it be excluded from
> /proc/iomem?
>
> Should this be fixed in the kernel?
>
> Or, is the provided DTB incorrect?
> Should the memory node exclude the firmware area?


Which version of openSBI are you using? We fixed something similar in 
1.3 by reintroducing the "nomap" property to the regions occupied by 
openSBI, I'd say it should be enough, let me know if it's not!

Thanks,

Alex


>
> Petr T
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: How to deal with openSBI reserved regions?

[Petr Tesarik]

Hi Alexandre,

On 7/28/2023 12:36 PM, Alexandre Ghiti wrote:
> Hi Petr,
> 
> 
> On 28/07/2023 12:02, Petr Tesarik wrote:
>> Hi all,
>>
>> I have recently looked into enabling crash kernel and kdump on riscv64.
>> I can start a new kernel after crash, but I ran into an issue when
>> reading /proc/vmcore there.
>>
>> I am testing this inside a QEMU VM and I boot my system in S-Mode using
>> U-Boot with mbedded openSBI firmware. The problem here is that openSBI
>> occupies the first 128 pages of RAM, but they are shown as "System RAM"
>> in /proc/iomem. The kexec_file_load(2) system call uses
>> walk_system_ram_res() to build a memory map of the currently running
>> kernel. This is then passed to the crash kernel through ELF core headers
>> as a LOAD segment. When reading the corresponding part of /proc/iomem,
>> the crash kernel tries to map these pages, but they can be accessed only
>> from M-Mode. Any attempt to access them from the Linux kernel fails with
>> a PMP violation. Consequently, -EFAULT is returned to user space.
>>
>> Now, the openSBI area is represented in the Device Tree with a
>> reserved-memory node () which overlaps a memory node. Technically, the
>> firmware region is indeed RAM, but how should it be excluded from
>> /proc/iomem?
>>
>> Should this be fixed in the kernel?
>>
>> Or, is the provided DTB incorrect?
>> Should the memory node exclude the firmware area?
> 
> 
> Which version of openSBI are you using? We fixed something similar in
> 1.3 by reintroducing the "nomap" property to the regions occupied by
> openSBI, I'd say it should be enough, let me know if it's not!

It took me some time to find out which version of OpenSBI was actually
used, and it was OpenSBI 1.2, built from a copy in the QEMU 8.0.3 source
tree.

I rebuilt openSBI from git sources, and I can confirm that commit
8153b2622b08 fixes the issue for me. It allows me to read the complete
/proc/vmcore from a crash kernel environment. In short, the "no-map"
attribute is also sufficient here.

Thanks for the advice!

Petr T


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: How to deal with openSBI reserved regions?

[Andreas Schwab]

On Jul 28 2023, Petr Tesarik wrote:

> Or, is the provided DTB incorrect?
> Should the memory node exclude the firmware area?

It should be marked as reserved memory.

# ls /sys/firmware/devicetree/base/reserved-memory
#address-cells  mmode_resv0@80040000/  name
#size-cells     mmode_resv1@80000000/  ranges

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv