Le mer. 11 oct. 2023, 12:20, Wu, Fei <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?

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

Reply via email to