[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Relocation overflow on RISC-V with multi-range memory layout
|
From: |
Vladimir 'phcoder' Serbinenko |
|
Subject: |
Re: Relocation overflow on RISC-V with multi-range memory layout |
|
Date: |
Sat, 14 Oct 2023 23:16:10 +0200 |
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