grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Relocation overflow on RISC-V with multi-range memory layout


From: Wu, Fei
Subject: Re: Relocation overflow on RISC-V with multi-range memory layout
Date: Thu, 12 Oct 2023 08:29:53 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.15.1

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>
>     >
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]