Inconsistent return value ABI for Aarch64

[AndrewFasano]

Note that this issue is partly just me adding some documentation since we don't have a readme in here - I think most of us already know this, but it wasn't explicitly spelled out. And then there is an issue with aarch64.

Hypercalls should use a consistent ABI for various guest architectures. Of course, the ABIs are different between architectures, so we need to make this consistency relative to something else. We standardized on using the same interface as what each architecture uses to pass syscall number + arguments which allows us to use the following panda code with libhc:

@panda.cb_guest_hypercall
def before_hc(cpu):
  magic = panda.arch.get_arg(cpu, 0, convention='syscall')
  type = panda.arch.get_arg(cpu, 1, convention='syscall')
  data  = panda.arch.get_arg(cpu, 2, convention='syscall')
  len = panda.arch.get_arg(cpu, 3, convention='syscall')

  return_value = 0x1234 # Value to be returned
  panda.arch.set_arg(cpu, 0, return_value, convention='syscall')

It would be great if we could add unit tests to validate this, but in the short term, I'm just going to walk through them all to figure out if there's an inconsistency in here to explain some behavior I'm seeing. After running through them all (below), it seems Aarch64 return value handling is incorrect.

X86_64: Matches syscall arg order

• Magic in RAX
• Type in RDI
• Data in RSI
• Len in RDX
• Return value in RAX

X86: Matches syscall arg order

• Magic in EAX
• Type in EBX
• Data in ECX
• Len in EDX
• Return value in RAX

ARM: Matches syscall (EABI) arg order

• Magic in R7
• Type in R0
• Data in R1
• Len in R2
• Return in R7

MIPS 32 & 64 (identical): Matches syscall arg order

• Magic in $2 -> V0
• Type in $4 -> A0
• Data in $5 -> A1
• Len in $6 -> A2
• Return in $2 -> V0

Aarch64: Inconsistent!!

• Magic in X8
• Type in X0
• Data in X1
• Len in X2
• Needless zero of X3?
• Return in in X0 Wrong