On 10/11/2023 9:50 PM, Vladimir 'phcoder' Serbinenko wrote: > > > Le mer. 11 oct. 2023, 12:20, Wu, Fei <fei2...@intel.com > <mailto:fei2...@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...@intel.com > <mailto:fei2...@intel.com> > >> <mailto:fei2...@intel.com <mailto:fei2...@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+yekhcy...@mail.gmail.com/T/ > > <https://lore.kernel.org/all/cakmqykmtazt5sacumd4vxyfgaqibpzqjahttsusb+yekhcy...@mail.gmail.com/T/> > > <https://lore.kernel.org/all/cakmqykmtazt5sacumd4vxyfgaqibpzqjahttsusb+yekhcy...@mail.gmail.com/T/ > > <https://lore.kernel.org/all/cakmqykmtazt5sacumd4vxyfgaqibpzqjahttsusb+yekhcy...@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
