2

I recently started writing a native hypervisor, and in order to support a multicore system, I must initialize the hypervisor on all cores. Using Intel's x2APIC, I am sending a SIPI interrupt from the BSP to other cores. After issuing the interrupt, I am unable to call a function that resides in a different file (a C function) using the name of the function. When I am trying to do that, the CPU runs into a triple fault.

The code looks like this (generated using objdump -dj .text):

000000000330049c <ApicLongMode>:
330049c: mov    $0x770000,%esp
33004a1: mov    0x4000,%rdi
33004a9: callq  3303a2c <InitializeSingleHypervisor>

However, the call succeeds when using the address of the function instead of its name:

000000000330049c <ApicLongMode>:
330049c: mov    $0x770000,%esp
33004a1: mov    0x4000,%rdi
33004a9: callq  *0x4008

In the above case, the address 0x4008 contains the address of the InitializeSingleHypervisor function.

Note that when I am running the exact same code (the first piece of code) from the BSP, the function is successfully called.

I am using nasm as an assembler and ld as a linker. Of course, I have made sure to declare the function as extern before calling it.

Can someone explain this behavior?

  • This looks a lot like your code was incorrectly linked or loaded. Please make a [mcve] if possible as with the information provided, it'll be difficult to diagnose the problem. – fuz Oct 08 '20 at 21:48
  • @fuz Thank you for your comment. – Amir Shalom Yeshooroon Oct 08 '20 at 21:56
  • @fuz I understand that it is not possible to reproduce the problem with the provided code, but in order to do that the whole system must be compiled (including the bootloader and many other files). [Here](https://github.com/amiryeshurun/windows-native-hypervisor/blob/master/makefile) is the makefile that I am using in order to compile & link all of the files. As I described, I am able to call the mentioned function when running on the bootstrap processor. I encounter the error only when running on other cores. Taking this into consideration, why are you suspecting incorrect linking? – Amir Shalom Yeshooroon Oct 08 '20 at 22:07
  • Are you sure that rsp points to accessible memory? A page fault on a stack access will surely lead to a triple fault, – prl Oct 09 '20 at 04:08
  • Is your code loaded at the same address in both BSP and AP? If the absolute call works, could the problem be due to the relative offset not leading to the destination? – prl Oct 09 '20 at 04:10
  • 1
    I suggest you get fault handling set up on the APs as a top priority. It will help in debugging all manner of problems like this one. – prl Oct 09 '20 at 04:11
  • @prl Thanks for commenting! Yes, the memory is definitely mapped. At initialization time, I am mapping all of the memory, and I am using the exact same PML4 base address in all cores (meaning, CR3 is loaded with the same value). Thus, if core A can access address X, then core B can access X as well. – Amir Shalom Yeshooroon Oct 09 '20 at 10:41
  • I understand you’re using the same cr3, but surely rsp is different. – prl Oct 09 '20 at 16:20

0 Answers0