Unify hypercall code

[be32826]

Currently, we have three hypercall implementations:

• libhc
• ad-hoc in kernel
• ad-hoc in libnvram

They have different APIs and probably have bugs that don't exist in the others. We should unify them to all use the same code from the same repo. We can also use this as an opportunity to change the API if we want.

[AndrewFasano]

Related to #238 - maybe we should close one of those depending on what you and @caden-kline think.

[caden-kline]

decided to close #238 and continue with this one

[caden-kline]

The current plan is to take the model from the kernel hypercall.h and replace libhc. The new libhc will use preprocessor/marcos so that hypercall3 is hypercall2 + register. with hypercalls1-5. I also intend to have a compatible hc that calls the correct hypercall3. It would be ideal to later transistion current libhc users from hc towards the new methods. I suspect it's possible that the somethings like the kernel will have a wrapper around the new hypercall so that things like CONFIG_ARM vs TARGET_ARM are handled correctly.

[caden-kline]

#define declare_register(x,y,z) register unsigned long regx asm("y") = z;
#define register1 declare_register(0,r7,num)
#define register2 register1 declare_register(1,r0,arg0)

Example macro better ideas on how to write this are welcome

[AndrewFasano]

Macros are fun but maybe overkill here? I'd think we could basically just take the existing code we have in the kernel https://github.com/rehosting/linux/blob/d5b61c5aa848109d36ef2531d32d07875e4bc092/include/linux/hypercall.h
and combine that with libhc. I think this should be fairly straightforward? Then we'd ultimately want to add libhc as a submodule in our linux kernel like how it's set up in other places.

After that we could also consider changing some of the current code that uses libhc to pass integers/pointers directly (when it makes sense) instead of the pointer-to-pointer method those codebases are currently using. Perhaps we rename some methods along the way.

To get the preprocessor macros to work in the kernel, we'll probably need something like a simple (kernel-specific) header like:

#ifdef CONFIG_X86
#define __x86_64__
#endif
...

[caden-kline]

A few questions that need to be solved.

• inlining vs not. harder on static analysis but gives access to PC.
• convenience features like retry codes and data paging in. (personally I would like to avoid handling this in the libhc)

[AndrewFasano]

I'm pro inlining, means we can look at the PC and map it back to original source location more easily and also helps with performance. If there's a good reason not to, I'd be open to it.

I don't think we should automatically handle paging memory in for the standard hypercall methods (i.e., the ones we have in the linux kernel that just take 1-2 arguments and return a value). I think that should be left to the end user as the library won't know what the structure of the data is and paging it in is difficult to do in the general case.

If we keep the current static inline int hc(int hc_type, void **s,int len) method, maybe we'd want to support paging things in there? I'd be thrilled if we could delete this method entirely.

I think it could be good to:

1. Have a convention for how someone could raise a "paged out memory" error and indicate this in a standard way
2. Provide a "page in data" method which takes a pointer and a size. It's going to be trivial and small, but good to avoid making users re-invent this every time.

[caden-kline]

my current recommendation is to alias hc to the hypercall4 and then transition everything away from hc.

[AndrewFasano]

Isn't the current hc method a bit different than just a 4-arg hypercall? Like it has a more specific contract involving pointers to pointers and auto-paging stuff in.

I think replacing it with hypercall4 (not just aliasing it) and then updating all the uses of it would be a good plan.

[AndrewFasano]

Caden started a first draft, but hasn't pushed it yet - will do so soon

[caden-kline]

https://github.com/panda-re/libhc/tree/libhc_rewrite rough draft.