* Relocation overflow on RISC-V with multi-range memory layout
@ 2023-09-25 8:51 Wu, Fei
2023-09-27 6:16 ` Wu, Fei
2023-09-27 15:23 ` Vladimir 'phcoder' Serbinenko
0 siblings, 2 replies; 10+ messages in thread
From: Wu, Fei @ 2023-09-25 8:51 UTC (permalink / raw
To: grub-devel, agraf, Alistair Francis
Hi All,
I'm enabling PCIe passthrough on qemu riscv, the physical memory
range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram,
two ranges are created as [2G, 3G) and [4G, 7G). More details can be
found here:
https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/
When run grub.efi from uefi shell, a relocation problem happened in
grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c:
case R_RISCV_CALL:
case R_RISCV_CALL_PLT:
{
grub_uint32_t *abs_place = place;
grub_ssize_t off = sym_addr - (grub_addr_t) place;
grub_uint32_t hi20, lo12;
if (off != (grub_int32_t) off)
return grub_error (GRUB_ERR_BAD_MODULE, "relocation
overflow");
It requires `off' in the range of int32, but it's not enforced since the
>4GB memory can be used. I'm not familiar with grub, but this patch does
work for me:
--- a/include/grub/riscv64/efi/memory.h
+++ b/include/grub/riscv64/efi/memory.h
@@ -1,6 +1,6 @@
#ifndef GRUB_MEMORY_CPU_HEADER
#include <grub/efi/memory.h>
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL
+#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL
Any comments?
Thanks,
Fei.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-09-25 8:51 Relocation overflow on RISC-V with multi-range memory layout Wu, Fei @ 2023-09-27 6:16 ` Wu, Fei 2023-09-27 10:08 ` Daniel Kiper 2023-09-27 15:23 ` Vladimir 'phcoder' Serbinenko 1 sibling, 1 reply; 10+ messages in thread From: Wu, Fei @ 2023-09-27 6:16 UTC (permalink / raw To: grub-devel, agraf, Alistair Francis On 9/25/2023 4:51 PM, Wu, Fei wrote: > Hi All, > > I'm enabling PCIe passthrough on qemu riscv, the physical memory > range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram, > two ranges are created as [2G, 3G) and [4G, 7G). More details can be > found here: > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ > > When run grub.efi from uefi shell, a relocation problem happened in > grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > > case R_RISCV_CALL: > case R_RISCV_CALL_PLT: > { > grub_uint32_t *abs_place = place; > grub_ssize_t off = sym_addr - (grub_addr_t) place; > grub_uint32_t hi20, lo12; > > if (off != (grub_int32_t) off) > return grub_error (GRUB_ERR_BAD_MODULE, "relocation > overflow"); > > It requires `off' in the range of int32, but it's not enforced since the >> 4GB memory can be used. I'm not familiar with grub, but this patch does > work for me: > > --- a/include/grub/riscv64/efi/memory.h > +++ b/include/grub/riscv64/efi/memory.h > @@ -1,6 +1,6 @@ > #ifndef GRUB_MEMORY_CPU_HEADER > #include <grub/efi/memory.h> > > -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > Anyone can help take a look? I will send it out for review if this is the right fix. The test I have done against commit db1faedcc: qemu-system-riscv64 -nographic \ -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ -m 3G -smp 2 \ -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ -device virtio-blk-device,drive=hd0 \ -drive file=fat:rw:/home/wufei/src/fat,id=hd0 then run grubriscv64.efi on uefi shell: FS0:\> grubriscv64.efi ... ProtectUefiImageCommon - 0xBED9E540 - 0x00000000BDCCB000 - 0x00000000004DF000 SetUefiImageMemoryAttributes - 0x00000000BDCCB000 - 0x0000000000001000 (0x0000000000004000) CpuSetMemoryAttributes: Set memory attributes not supported yet SetUefiImageMemoryAttributes - 0x00000000BDCCC000 - 0x000000000000C000 (0x0000000000020000) CpuSetMemoryAttributes: Set memory attributes not supported yet SetUefiImageMemoryAttributes - 0x00000000BDCD8000 - 0x00000000004D2000 (0x0000000000004000) CpuSetMemoryAttributes: Set memory attributes not supported yet InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 83FFF720 CpuSetMemoryAttributes: Set memory attributes not supported yet relocation overflow Aborted. Press any key to exit Thanks, Fei. > Any comments? > > Thanks, > Fei. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-09-27 6:16 ` Wu, Fei @ 2023-09-27 10:08 ` Daniel Kiper 0 siblings, 0 replies; 10+ messages in thread From: Daniel Kiper @ 2023-09-27 10:08 UTC (permalink / raw To: Wu, Fei; +Cc: grub-devel, agraf, Alistair Francis, atishp Adding Atish... On Wed, Sep 27, 2023 at 02:16:40PM +0800, Wu, Fei wrote: > On 9/25/2023 4:51 PM, Wu, Fei wrote: > > Hi All, > > > > I'm enabling PCIe passthrough on qemu riscv, the physical memory > > range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram, > > two ranges are created as [2G, 3G) and [4G, 7G). More details can be > > found here: > > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ > > > > When run grub.efi from uefi shell, a relocation problem happened in > > grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > > > > case R_RISCV_CALL: > > case R_RISCV_CALL_PLT: > > { > > grub_uint32_t *abs_place = place; > > grub_ssize_t off = sym_addr - (grub_addr_t) place; > > grub_uint32_t hi20, lo12; > > > > if (off != (grub_int32_t) off) > > return grub_error (GRUB_ERR_BAD_MODULE, "relocation > > overflow"); > > > > It requires `off' in the range of int32, but it's not enforced since the > >> 4GB memory can be used. I'm not familiar with grub, but this patch does > > work for me: > > > > --- a/include/grub/riscv64/efi/memory.h > > +++ b/include/grub/riscv64/efi/memory.h > > @@ -1,6 +1,6 @@ > > #ifndef GRUB_MEMORY_CPU_HEADER > > #include <grub/efi/memory.h> > > > > -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > > +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > > > Anyone can help take a look? I will send it out for review if this is > the right fix. > > The test I have done against commit db1faedcc: > > qemu-system-riscv64 -nographic \ > -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ > -m 3G -smp 2 \ > -blockdev > node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ > -device virtio-blk-device,drive=hd0 \ > -drive file=fat:rw:/home/wufei/src/fat,id=hd0 > > then run grubriscv64.efi on uefi shell: > > FS0:\> grubriscv64.efi > ... > ProtectUefiImageCommon - 0xBED9E540 > - 0x00000000BDCCB000 - 0x00000000004DF000 > SetUefiImageMemoryAttributes - 0x00000000BDCCB000 - 0x0000000000001000 > (0x0000000000004000) > CpuSetMemoryAttributes: Set memory attributes not supported yet > SetUefiImageMemoryAttributes - 0x00000000BDCCC000 - 0x000000000000C000 > (0x0000000000020000) > CpuSetMemoryAttributes: Set memory attributes not supported yet > SetUefiImageMemoryAttributes - 0x00000000BDCD8000 - 0x00000000004D2000 > (0x0000000000004000) > CpuSetMemoryAttributes: Set memory attributes not supported yet > InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 83FFF720 > CpuSetMemoryAttributes: Set memory attributes not supported yet > relocation overflow > Aborted. Press any key to exit > > Thanks, > Fei. > > Any comments? > > > > Thanks, > > Fei. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-09-25 8:51 Relocation overflow on RISC-V with multi-range memory layout Wu, Fei 2023-09-27 6:16 ` Wu, Fei @ 2023-09-27 15:23 ` Vladimir 'phcoder' Serbinenko 2023-10-09 3:14 ` Wu, Fei 1 sibling, 1 reply; 10+ messages in thread From: Vladimir 'phcoder' Serbinenko @ 2023-09-27 15:23 UTC (permalink / raw To: The development of GNU GRUB [-- Attachment #1.1: Type: text/plain, Size: 1747 bytes --] That is not the correct solution. Correct solution is to use trampoline facility like e.g. ppc does. Can you post the full reproduction instructions? Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com> a écrit : > Hi All, > > I'm enabling PCIe passthrough on qemu riscv, the physical memory > range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram, > two ranges are created as [2G, 3G) and [4G, 7G). More details can be > found here: > > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ > > When run grub.efi from uefi shell, a relocation problem happened in > grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > > case R_RISCV_CALL: > case R_RISCV_CALL_PLT: > { > grub_uint32_t *abs_place = place; > grub_ssize_t off = sym_addr - (grub_addr_t) place; > grub_uint32_t hi20, lo12; > > if (off != (grub_int32_t) off) > return grub_error (GRUB_ERR_BAD_MODULE, "relocation > overflow"); > > It requires `off' in the range of int32, but it's not enforced since the > >4GB memory can be used. I'm not familiar with grub, but this patch does > work for me: > > --- a/include/grub/riscv64/efi/memory.h > +++ b/include/grub/riscv64/efi/memory.h > @@ -1,6 +1,6 @@ > #ifndef GRUB_MEMORY_CPU_HEADER > #include <grub/efi/memory.h> > > -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > > Any comments? > > Thanks, > Fei. > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > [-- Attachment #1.2: Type: text/html, Size: 2511 bytes --] [-- Attachment #2: Type: text/plain, Size: 141 bytes --] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-09-27 15:23 ` Vladimir 'phcoder' Serbinenko @ 2023-10-09 3:14 ` Wu, Fei 2023-10-11 10:20 ` Wu, Fei 0 siblings, 1 reply; 10+ messages in thread From: Wu, Fei @ 2023-10-09 3:14 UTC (permalink / raw To: The development of GNU GRUB, Vladimir 'phcoder' Serbinenko On 9/27/2023 11:23 PM, Vladimir 'phcoder' Serbinenko wrote: > That is not the correct solution. Correct solution is to use trampoline > facility like e.g. ppc does. Can you post the full reproduction > instructions? > 1. prepare the host for pcie passthrough, e.g. on ubuntu, put something like the following to kernel cmd, the pci ids are the pci devices to passthrough: intel_iommu=on iommu=pt vfio-pci.ids=10de:0f02,10de:0e08 2. apply the patch mentioned below to qemu commit ccb86f079a9e4 3. run qemu as follows: qemu-system-riscv64 -nographic \ -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ -m 3G -smp 2 \ -blockdev node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ -device virtio-blk-device,drive=hd0 \ -drive file=fat:rw:/home/wufei/src/fat,id=hd0 4. build and put grub.efi to the directory 'fat' 5. on uefi shell, run grub.efi Thanks, Fei. > Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com > <mailto:fei2.wu@intel.com>> a écrit : > > Hi All, > > I'm enabling PCIe passthrough on qemu riscv, the physical memory > range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram, > two ranges are created as [2G, 3G) and [4G, 7G). More details can be > found here: > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/> > > When run grub.efi from uefi shell, a relocation problem happened in > grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > > case R_RISCV_CALL: > case R_RISCV_CALL_PLT: > { > grub_uint32_t *abs_place = place; > grub_ssize_t off = sym_addr - (grub_addr_t) place; > grub_uint32_t hi20, lo12; > > if (off != (grub_int32_t) off) > return grub_error (GRUB_ERR_BAD_MODULE, "relocation > overflow"); > > It requires `off' in the range of int32, but it's not enforced since the > >4GB memory can be used. I'm not familiar with grub, but this patch does > work for me: > > --- a/include/grub/riscv64/efi/memory.h > +++ b/include/grub/riscv64/efi/memory.h > @@ -1,6 +1,6 @@ > #ifndef GRUB_MEMORY_CPU_HEADER > #include <grub/efi/memory.h> > > -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > > Any comments? > > Thanks, > Fei. > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > https://lists.gnu.org/mailman/listinfo/grub-devel > <https://lists.gnu.org/mailman/listinfo/grub-devel> > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-10-09 3:14 ` Wu, Fei @ 2023-10-11 10:20 ` Wu, Fei 2023-10-11 13:50 ` Vladimir 'phcoder' Serbinenko 0 siblings, 1 reply; 10+ messages in thread From: Wu, Fei @ 2023-10-11 10:20 UTC (permalink / raw To: The development of GNU GRUB, Vladimir 'phcoder' Serbinenko On 10/9/2023 11:14 AM, Wu, Fei wrote: > On 9/27/2023 11:23 PM, Vladimir 'phcoder' Serbinenko wrote: >> That is not the correct solution. Correct solution is to use trampoline >> facility like e.g. ppc does. Can you post the full reproduction >> instructions? >> Hi Vladimir, Could you please explain a little more about why this is not good, and how does the trampoline address that? IIUC, x86_64 sets GRUB_EFI_MAX_USABLE_ADDRESS to 0xffffffff for the same reason. Thanks, Fei. > 1. prepare the host for pcie passthrough, e.g. on ubuntu, put something > like the following to kernel cmd, the pci ids are the pci devices to > passthrough: > intel_iommu=on iommu=pt vfio-pci.ids=10de:0f02,10de:0e08 > > 2. apply the patch mentioned below to qemu commit ccb86f079a9e4 > 3. run qemu as follows: > > qemu-system-riscv64 > -nographic \ > -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ > -m 3G -smp 2 \ > -blockdev > node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ > -device virtio-blk-device,drive=hd0 \ > -drive file=fat:rw:/home/wufei/src/fat,id=hd0 > > 4. build and put grub.efi to the directory 'fat' > 5. on uefi shell, run grub.efi > > Thanks, > Fei. > >> Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com >> <mailto:fei2.wu@intel.com>> a écrit : >> >> Hi All, >> >> I'm enabling PCIe passthrough on qemu riscv, the physical memory >> range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram, >> two ranges are created as [2G, 3G) and [4G, 7G). More details can be >> found here: >> https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/> >> >> When run grub.efi from uefi shell, a relocation problem happened in >> grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: >> >> case R_RISCV_CALL: >> case R_RISCV_CALL_PLT: >> { >> grub_uint32_t *abs_place = place; >> grub_ssize_t off = sym_addr - (grub_addr_t) place; >> grub_uint32_t hi20, lo12; >> >> if (off != (grub_int32_t) off) >> return grub_error (GRUB_ERR_BAD_MODULE, "relocation >> overflow"); >> >> It requires `off' in the range of int32, but it's not enforced since the >> >4GB memory can be used. I'm not familiar with grub, but this patch does >> work for me: >> >> --- a/include/grub/riscv64/efi/memory.h >> +++ b/include/grub/riscv64/efi/memory.h >> @@ -1,6 +1,6 @@ >> #ifndef GRUB_MEMORY_CPU_HEADER >> #include <grub/efi/memory.h> >> >> -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL >> +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL >> >> Any comments? >> >> Thanks, >> Fei. >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> >> https://lists.gnu.org/mailman/listinfo/grub-devel >> <https://lists.gnu.org/mailman/listinfo/grub-devel> >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-10-11 10:20 ` Wu, Fei @ 2023-10-11 13:50 ` Vladimir 'phcoder' Serbinenko 2023-10-12 0:29 ` Wu, Fei 0 siblings, 1 reply; 10+ messages in thread From: Vladimir 'phcoder' Serbinenko @ 2023-10-11 13:50 UTC (permalink / raw To: Wu, Fei; +Cc: The development of GNU GRUB [-- Attachment #1.1: Type: text/plain, Size: 4320 bytes --] Le mer. 11 oct. 2023, 12:20, Wu, Fei <fei2.wu@intel.com> a écrit : > On 10/9/2023 11:14 AM, Wu, Fei wrote: > > On 9/27/2023 11:23 PM, Vladimir 'phcoder' Serbinenko wrote: > >> That is not the correct solution. Correct solution is to use trampoline > >> facility like e.g. ppc does. Can you post the full reproduction > >> instructions? > >> > Hi Vladimir, > > Could you please explain a little more about why this is not good, and > how does the trampoline address that? IIUC, x86_64 sets > GRUB_EFI_MAX_USABLE_ADDRESS to 0xffffffff for the same reason. > x86_64 reason is different. It's because some EFI implementations don't map RAM above 4GiB contrary to the spec. Trampolines are small piece of code that is inserted by linker to provide absolute jump. Trampolines are always allocated together with the module and so they are reachable by relative jump. Basically what they do then is: ptr=&symbol; return (*ptr) (...); On most platforms that translates to a load+register jump. Let me see if I can do it quickly. Will you be able to test? > > Thanks, > Fei. > > > 1. prepare the host for pcie passthrough, e.g. on ubuntu, put something > > like the following to kernel cmd, the pci ids are the pci devices to > > passthrough: > > intel_iommu=on iommu=pt vfio-pci.ids=10de:0f02,10de:0e08 > > > > 2. apply the patch mentioned below to qemu commit ccb86f079a9e4 > > 3. run qemu as follows: > > > > qemu-system-riscv64 > > -nographic \ > > -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ > > -m 3G -smp 2 \ > > -blockdev > > node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > > -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ > > -device virtio-blk-device,drive=hd0 \ > > -drive file=fat:rw:/home/wufei/src/fat,id=hd0 > > > > 4. build and put grub.efi to the directory 'fat' > > 5. on uefi shell, run grub.efi > > > > Thanks, > > Fei. > > > >> Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com > >> <mailto:fei2.wu@intel.com>> a écrit : > >> > >> Hi All, > >> > >> I'm enabling PCIe passthrough on qemu riscv, the physical memory > >> range between 3GB and 4GB is reserved. Therefore if guest has 4GB > ram, > >> two ranges are created as [2G, 3G) and [4G, 7G). More details can be > >> found here: > >> > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ > < > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ > > > >> > >> When run grub.efi from uefi shell, a relocation problem happened in > >> grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > >> > >> case R_RISCV_CALL: > >> case R_RISCV_CALL_PLT: > >> { > >> grub_uint32_t *abs_place = place; > >> grub_ssize_t off = sym_addr - (grub_addr_t) place; > >> grub_uint32_t hi20, lo12; > >> > >> if (off != (grub_int32_t) off) > >> return grub_error (GRUB_ERR_BAD_MODULE, "relocation > >> overflow"); > >> > >> It requires `off' in the range of int32, but it's not enforced > since the > >> >4GB memory can be used. I'm not familiar with grub, but this patch > does > >> work for me: > >> > >> --- a/include/grub/riscv64/efi/memory.h > >> +++ b/include/grub/riscv64/efi/memory.h > >> @@ -1,6 +1,6 @@ > >> #ifndef GRUB_MEMORY_CPU_HEADER > >> #include <grub/efi/memory.h> > >> > >> -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > >> +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > >> > >> Any comments? > >> > >> Thanks, > >> Fei. > >> > >> _______________________________________________ > >> Grub-devel mailing list > >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > >> https://lists.gnu.org/mailman/listinfo/grub-devel > >> <https://lists.gnu.org/mailman/listinfo/grub-devel> > >> > >> > >> _______________________________________________ > >> Grub-devel mailing list > >> Grub-devel@gnu.org > >> https://lists.gnu.org/mailman/listinfo/grub-devel > > > > [-- Attachment #1.2: Type: text/html, Size: 6721 bytes --] [-- Attachment #2: Type: text/plain, Size: 141 bytes --] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-10-11 13:50 ` Vladimir 'phcoder' Serbinenko @ 2023-10-12 0:29 ` Wu, Fei 2023-10-14 21:16 ` Vladimir 'phcoder' Serbinenko 0 siblings, 1 reply; 10+ messages in thread From: Wu, Fei @ 2023-10-12 0:29 UTC (permalink / raw To: Vladimir 'phcoder' Serbinenko; +Cc: The development of GNU GRUB On 10/11/2023 9:50 PM, Vladimir 'phcoder' Serbinenko wrote: > > > Le mer. 11 oct. 2023, 12:20, Wu, Fei <fei2.wu@intel.com > <mailto:fei2.wu@intel.com>> a écrit : > > On 10/9/2023 11:14 AM, Wu, Fei wrote: > > On 9/27/2023 11:23 PM, Vladimir 'phcoder' Serbinenko wrote: > >> That is not the correct solution. Correct solution is to use > trampoline > >> facility like e.g. ppc does. Can you post the full reproduction > >> instructions? > >> > Hi Vladimir, > > Could you please explain a little more about why this is not good, and > how does the trampoline address that? IIUC, x86_64 sets > GRUB_EFI_MAX_USABLE_ADDRESS to 0xffffffff for the same reason. > > x86_64 reason is different. It's because some EFI implementations don't > map RAM above 4GiB contrary to the spec. > Trampolines are small piece of code that is inserted by linker to > provide absolute jump. Trampolines are always allocated together with > the module and so they are reachable by relative jump. Basically what > they do then is: > ptr=&symbol; > return (*ptr) (...); > On most platforms that translates to a load+register jump. Let me see if > I can do it quickly. Will you be able to test? > Thank you Vladimir. Sure, I can test it, let me know when your code is ready. Best Regards, Fei. > > Thanks, > Fei. > > > 1. prepare the host for pcie passthrough, e.g. on ubuntu, put > something > > like the following to kernel cmd, the pci ids are the pci devices to > > passthrough: > > intel_iommu=on iommu=pt vfio-pci.ids=10de:0f02,10de:0e08 > > > > 2. apply the patch mentioned below to qemu commit ccb86f079a9e4 > > 3. run qemu as follows: > > > > qemu-system-riscv64 > > -nographic \ > > -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ > > -m 3G -smp 2 \ > > -blockdev > > > node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > > -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ > > -device virtio-blk-device,drive=hd0 \ > > -drive file=fat:rw:/home/wufei/src/fat,id=hd0 > > > > 4. build and put grub.efi to the directory 'fat' > > 5. on uefi shell, run grub.efi > > > > Thanks, > > Fei. > > > >> Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com > <mailto:fei2.wu@intel.com> > >> <mailto:fei2.wu@intel.com <mailto:fei2.wu@intel.com>>> a écrit : > >> > >> Hi All, > >> > >> I'm enabling PCIe passthrough on qemu riscv, the physical memory > >> range between 3GB and 4GB is reserved. Therefore if guest has > 4GB ram, > >> two ranges are created as [2G, 3G) and [4G, 7G). More details > can be > >> found here: > >> > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/> <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/>> > >> > >> When run grub.efi from uefi shell, a relocation problem > happened in > >> grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > >> > >> case R_RISCV_CALL: > >> case R_RISCV_CALL_PLT: > >> { > >> grub_uint32_t *abs_place = place; > >> grub_ssize_t off = sym_addr - (grub_addr_t) place; > >> grub_uint32_t hi20, lo12; > >> > >> if (off != (grub_int32_t) off) > >> return grub_error (GRUB_ERR_BAD_MODULE, "relocation > >> overflow"); > >> > >> It requires `off' in the range of int32, but it's not > enforced since the > >> >4GB memory can be used. I'm not familiar with grub, but this > patch does > >> work for me: > >> > >> --- a/include/grub/riscv64/efi/memory.h > >> +++ b/include/grub/riscv64/efi/memory.h > >> @@ -1,6 +1,6 @@ > >> #ifndef GRUB_MEMORY_CPU_HEADER > >> #include <grub/efi/memory.h> > >> > >> -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > >> +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > >> > >> Any comments? > >> > >> Thanks, > >> Fei. > >> > >> _______________________________________________ > >> Grub-devel mailing list > >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > <mailto:Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>> > >> https://lists.gnu.org/mailman/listinfo/grub-devel > <https://lists.gnu.org/mailman/listinfo/grub-devel> > >> <https://lists.gnu.org/mailman/listinfo/grub-devel > <https://lists.gnu.org/mailman/listinfo/grub-devel>> > >> > >> > >> _______________________________________________ > >> Grub-devel mailing list > >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > >> https://lists.gnu.org/mailman/listinfo/grub-devel > <https://lists.gnu.org/mailman/listinfo/grub-devel> > > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-10-12 0:29 ` Wu, Fei @ 2023-10-14 21:16 ` Vladimir 'phcoder' Serbinenko 2023-11-02 6:48 ` Wu, Fei 0 siblings, 1 reply; 10+ messages in thread From: Vladimir 'phcoder' Serbinenko @ 2023-10-14 21:16 UTC (permalink / raw To: Wu, Fei; +Cc: The development of GNU GRUB I looked into it and found out that current code misses both got and trampolines. I have a template for solution but I didn't test it yet. Can you upload your EFI images (RISCV_VIRT_CODE.fd and RISCV_VIRT_VARS.fd) somewhere so I don't have to compile myself? https://github.com/phcoder/GRUB/tree/riscv On Thu, Oct 12, 2023 at 2:30 AM Wu, Fei <fei2.wu@intel.com> wrote: > > On 10/11/2023 9:50 PM, Vladimir 'phcoder' Serbinenko wrote: > > > > > > Le mer. 11 oct. 2023, 12:20, Wu, Fei <fei2.wu@intel.com > > <mailto:fei2.wu@intel.com>> a écrit : > > > > On 10/9/2023 11:14 AM, Wu, Fei wrote: > > > On 9/27/2023 11:23 PM, Vladimir 'phcoder' Serbinenko wrote: > > >> That is not the correct solution. Correct solution is to use > > trampoline > > >> facility like e.g. ppc does. Can you post the full reproduction > > >> instructions? > > >> > > Hi Vladimir, > > > > Could you please explain a little more about why this is not good, and > > how does the trampoline address that? IIUC, x86_64 sets > > GRUB_EFI_MAX_USABLE_ADDRESS to 0xffffffff for the same reason. > > > > x86_64 reason is different. It's because some EFI implementations don't > > map RAM above 4GiB contrary to the spec. > > Trampolines are small piece of code that is inserted by linker to > > provide absolute jump. Trampolines are always allocated together with > > the module and so they are reachable by relative jump. Basically what > > they do then is: > > ptr=&symbol; > > return (*ptr) (...); > > On most platforms that translates to a load+register jump. Let me see if > > I can do it quickly. Will you be able to test? > > > Thank you Vladimir. Sure, I can test it, let me know when your code is > ready. > > Best Regards, > Fei. > > > > > Thanks, > > Fei. > > > > > 1. prepare the host for pcie passthrough, e.g. on ubuntu, put > > something > > > like the following to kernel cmd, the pci ids are the pci devices to > > > passthrough: > > > intel_iommu=on iommu=pt vfio-pci.ids=10de:0f02,10de:0e08 > > > > > > 2. apply the patch mentioned below to qemu commit ccb86f079a9e4 > > > 3. run qemu as follows: > > > > > > qemu-system-riscv64 > > > -nographic \ > > > -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ > > > -m 3G -smp 2 \ > > > -blockdev > > > > > node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ > > > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ > > > -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ > > > -device virtio-blk-device,drive=hd0 \ > > > -drive file=fat:rw:/home/wufei/src/fat,id=hd0 > > > > > > 4. build and put grub.efi to the directory 'fat' > > > 5. on uefi shell, run grub.efi > > > > > > Thanks, > > > Fei. > > > > > >> Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com > > <mailto:fei2.wu@intel.com> > > >> <mailto:fei2.wu@intel.com <mailto:fei2.wu@intel.com>>> a écrit : > > >> > > >> Hi All, > > >> > > >> I'm enabling PCIe passthrough on qemu riscv, the physical memory > > >> range between 3GB and 4GB is reserved. Therefore if guest has > > 4GB ram, > > >> two ranges are created as [2G, 3G) and [4G, 7G). More details > > can be > > >> found here: > > >> > > https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/> <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/>> > > >> > > >> When run grub.efi from uefi shell, a relocation problem > > happened in > > >> grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: > > >> > > >> case R_RISCV_CALL: > > >> case R_RISCV_CALL_PLT: > > >> { > > >> grub_uint32_t *abs_place = place; > > >> grub_ssize_t off = sym_addr - (grub_addr_t) place; > > >> grub_uint32_t hi20, lo12; > > >> > > >> if (off != (grub_int32_t) off) > > >> return grub_error (GRUB_ERR_BAD_MODULE, "relocation > > >> overflow"); > > >> > > >> It requires `off' in the range of int32, but it's not > > enforced since the > > >> >4GB memory can be used. I'm not familiar with grub, but this > > patch does > > >> work for me: > > >> > > >> --- a/include/grub/riscv64/efi/memory.h > > >> +++ b/include/grub/riscv64/efi/memory.h > > >> @@ -1,6 +1,6 @@ > > >> #ifndef GRUB_MEMORY_CPU_HEADER > > >> #include <grub/efi/memory.h> > > >> > > >> -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL > > >> +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL > > >> > > >> Any comments? > > >> > > >> Thanks, > > >> Fei. > > >> > > >> _______________________________________________ > > >> Grub-devel mailing list > > >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > > <mailto:Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>> > > >> https://lists.gnu.org/mailman/listinfo/grub-devel > > <https://lists.gnu.org/mailman/listinfo/grub-devel> > > >> <https://lists.gnu.org/mailman/listinfo/grub-devel > > <https://lists.gnu.org/mailman/listinfo/grub-devel>> > > >> > > >> > > >> _______________________________________________ > > >> Grub-devel mailing list > > >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > > >> https://lists.gnu.org/mailman/listinfo/grub-devel > > <https://lists.gnu.org/mailman/listinfo/grub-devel> > > > > > > -- Regards Vladimir 'phcoder' Serbinenko _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Relocation overflow on RISC-V with multi-range memory layout 2023-10-14 21:16 ` Vladimir 'phcoder' Serbinenko @ 2023-11-02 6:48 ` Wu, Fei 0 siblings, 0 replies; 10+ messages in thread From: Wu, Fei @ 2023-11-02 6:48 UTC (permalink / raw To: Vladimir 'phcoder' Serbinenko; +Cc: The development of GNU GRUB On 10/15/2023 5:16 AM, Vladimir 'phcoder' Serbinenko wrote: > I looked into it and found out that current code misses both got and > trampolines. I have a template for solution but I didn't test it yet. > Can you upload your EFI images (RISCV_VIRT_CODE.fd and > RISCV_VIRT_VARS.fd) somewhere so I don't have to compile myself? > https://github.com/phcoder/GRUB/tree/riscv > Do you have any update on this? Please let me know if you want me to have a try. Currently this branch doesn't work for me. Loading driver at 0x000BDCCD000 EntryPoint=0x000BDCCE000 ed yet InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BED98A18(0x0000000000004000) ProtectUefiImageCommon - 0xBED60040attributes not supported yet - 0x00000000BDCCD000 - 0x00000000004DD000C-A22A-E5F46812F4CA 83FFF720 SetUefiImageMemoryAttributes - 0x00000000BDCCD000 - 0x0000000000001000 (0x0000000000004000) CpuSetMemoryAttributes: Set memory attributes not supported yet SetUefiImageMemoryAttributes - 0x00000000BDCCE000 - 0x000000000000C000 (0x0000000000020000) CpuSetMemoryAttributes: Set memory attributes not supported yet SetUefiImageMemoryAttributes - 0x00000000BDCDA000 - 0x00000000004D0000 (0x0000000000004000) CpuSetMemoryAttributes: Set memory attributes not supported yet InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 83FFF720 !!!! RISCV64 Exception Type - 0000000000000005(EXCEPT_RISCV_LOAD_ACCESS_FAULT) !!!! t0 = 0x00000000000000047 t1 = 0x00000000083FFF370 t2 = 0x00000000000000043 t3 = 0x000000000752F3136 t4 = 0x00000000000004E16 t5 = 0x00000000000004FDC t6 = 0x00025100300200001 s0 = 0x00000000083FFF5F0 s1 = 0x00000000000000013 s2 = 0x00000000000000000 s3 = 0x00000000020000000 s4 = 0x00000000000000000 s5 = 0x000000000BDCDB0C0 s6 = 0x08000000A00006800 s7 = 0x0000000000000007F s8 = 0x0000000008001A038 s9 = 0x0000000008002AAB0 s10 = 0x00000000000000000 s11 = 0x00000000000000000 a0 = 0x000000000BDCDB0C0 a1 = 0x000000000BFFFE018 a2 = 0x000000000BDCD4F12 a3 = 0x000000000BED60E98 a4 = 0x000000000BFFFE018 a5 = 0x0AFAFAFAFAFAFAFAF a6 = 0x00000000000004FDC a7 = 0x000000000000000A2 zero = 0x00000000000000000 ra = 0x000000000BDCD2FA4 sp = 0x00000000000000010 gp = 0x00000000000000000 tp = 0x00000000080036000 sepc = 0x000000000BDCD1D9A sstatus = 0x08000000200006120 stval = 0x0AFAFAFAFAFAFAFAF Thanks, Fei. > On Thu, Oct 12, 2023 at 2:30 AM Wu, Fei <fei2.wu@intel.com> wrote: >> >> On 10/11/2023 9:50 PM, Vladimir 'phcoder' Serbinenko wrote: >>> >>> >>> Le mer. 11 oct. 2023, 12:20, Wu, Fei <fei2.wu@intel.com >>> <mailto:fei2.wu@intel.com>> a écrit : >>> >>> On 10/9/2023 11:14 AM, Wu, Fei wrote: >>> > On 9/27/2023 11:23 PM, Vladimir 'phcoder' Serbinenko wrote: >>> >> That is not the correct solution. Correct solution is to use >>> trampoline >>> >> facility like e.g. ppc does. Can you post the full reproduction >>> >> instructions? >>> >> >>> Hi Vladimir, >>> >>> Could you please explain a little more about why this is not good, and >>> how does the trampoline address that? IIUC, x86_64 sets >>> GRUB_EFI_MAX_USABLE_ADDRESS to 0xffffffff for the same reason. >>> >>> x86_64 reason is different. It's because some EFI implementations don't >>> map RAM above 4GiB contrary to the spec. >>> Trampolines are small piece of code that is inserted by linker to >>> provide absolute jump. Trampolines are always allocated together with >>> the module and so they are reachable by relative jump. Basically what >>> they do then is: >>> ptr=&symbol; >>> return (*ptr) (...); >>> On most platforms that translates to a load+register jump. Let me see if >>> I can do it quickly. Will you be able to test? >>> >> Thank you Vladimir. Sure, I can test it, let me know when your code is >> ready. >> >> Best Regards, >> Fei. >> >>> >>> Thanks, >>> Fei. >>> >>> > 1. prepare the host for pcie passthrough, e.g. on ubuntu, put >>> something >>> > like the following to kernel cmd, the pci ids are the pci devices to >>> > passthrough: >>> > intel_iommu=on iommu=pt vfio-pci.ids=10de:0f02,10de:0e08 >>> > >>> > 2. apply the patch mentioned below to qemu commit ccb86f079a9e4 >>> > 3. run qemu as follows: >>> > >>> > qemu-system-riscv64 >>> > -nographic \ >>> > -M virt,pflash0=pflash0,pflash1=pflash1,acpi=off \ >>> > -m 3G -smp 2 \ >>> > -blockdev >>> > >>> node-name=pflash0,driver=file,read-only=on,filename=RISCV_VIRT_CODE.fd \ >>> > -blockdev node-name=pflash1,driver=file,filename=RISCV_VIRT_VARS.fd \ >>> > -device vfio-pci,host=01:00.0 -device vfio-pci,host=01:00.1 \ >>> > -device virtio-blk-device,drive=hd0 \ >>> > -drive file=fat:rw:/home/wufei/src/fat,id=hd0 >>> > >>> > 4. build and put grub.efi to the directory 'fat' >>> > 5. on uefi shell, run grub.efi >>> > >>> > Thanks, >>> > Fei. >>> > >>> >> Le lun. 25 sept. 2023, 10:53, Wu, Fei <fei2.wu@intel.com >>> <mailto:fei2.wu@intel.com> >>> >> <mailto:fei2.wu@intel.com <mailto:fei2.wu@intel.com>>> a écrit : >>> >> >>> >> Hi All, >>> >> >>> >> I'm enabling PCIe passthrough on qemu riscv, the physical memory >>> >> range between 3GB and 4GB is reserved. Therefore if guest has >>> 4GB ram, >>> >> two ranges are created as [2G, 3G) and [4G, 7G). More details >>> can be >>> >> found here: >>> >> >>> https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/> <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/ <https://lore.kernel.org/all/CAKmqyKMtAzt5saCUMd4vXYfgAQibpzQJAhtTSuSb+yeKhcYpfw@mail.gmail.com/T/>> >>> >> >>> >> When run grub.efi from uefi shell, a relocation problem >>> happened in >>> >> grub_arch_dl_relocate_symbols() of grub-core/kern/riscv/dl.c: >>> >> >>> >> case R_RISCV_CALL: >>> >> case R_RISCV_CALL_PLT: >>> >> { >>> >> grub_uint32_t *abs_place = place; >>> >> grub_ssize_t off = sym_addr - (grub_addr_t) place; >>> >> grub_uint32_t hi20, lo12; >>> >> >>> >> if (off != (grub_int32_t) off) >>> >> return grub_error (GRUB_ERR_BAD_MODULE, "relocation >>> >> overflow"); >>> >> >>> >> It requires `off' in the range of int32, but it's not >>> enforced since the >>> >> >4GB memory can be used. I'm not familiar with grub, but this >>> patch does >>> >> work for me: >>> >> >>> >> --- a/include/grub/riscv64/efi/memory.h >>> >> +++ b/include/grub/riscv64/efi/memory.h >>> >> @@ -1,6 +1,6 @@ >>> >> #ifndef GRUB_MEMORY_CPU_HEADER >>> >> #include <grub/efi/memory.h> >>> >> >>> >> -#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL >>> >> +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffULL >>> >> >>> >> Any comments? >>> >> >>> >> Thanks, >>> >> Fei. >>> >> >>> >> _______________________________________________ >>> >> Grub-devel mailing list >>> >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> >>> <mailto:Grub-devel@gnu.org <mailto:Grub-devel@gnu.org>> >>> >> https://lists.gnu.org/mailman/listinfo/grub-devel >>> <https://lists.gnu.org/mailman/listinfo/grub-devel> >>> >> <https://lists.gnu.org/mailman/listinfo/grub-devel >>> <https://lists.gnu.org/mailman/listinfo/grub-devel>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Grub-devel mailing list >>> >> Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> >>> >> https://lists.gnu.org/mailman/listinfo/grub-devel >>> <https://lists.gnu.org/mailman/listinfo/grub-devel> >>> > >>> >> > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-11-02 6:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-09-25 8:51 Relocation overflow on RISC-V with multi-range memory layout Wu, Fei 2023-09-27 6:16 ` Wu, Fei 2023-09-27 10:08 ` Daniel Kiper 2023-09-27 15:23 ` Vladimir 'phcoder' Serbinenko 2023-10-09 3:14 ` Wu, Fei 2023-10-11 10:20 ` Wu, Fei 2023-10-11 13:50 ` Vladimir 'phcoder' Serbinenko 2023-10-12 0:29 ` Wu, Fei 2023-10-14 21:16 ` Vladimir 'phcoder' Serbinenko 2023-11-02 6:48 ` Wu, Fei
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).